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ABSTRACT 


After  the  attacks  of  9/11,  increased  security  became  a  national  priority  that 
resulted  in  a  focus  on  National  Maritime  Security.  Maritime  Domain  Awareness  (MDA) 
is  an  initiative  developed  by  the  Coast  Guard,  in  partnership  with  the  U.S.  Navy  and  other 
agencies  to  increase  awareness  in  the  maritime  domain  in  support  of  maritime  security 
[Morgan  and  Wiinmer,  2005]. 

The  purpose  of  MDA  is  to  generate  actionable  intelligence  obtained  via  the 
collection,  fusion  and  dissemination  of  information  from  U.S.  joint  forces,  U.S. 
government  agencies,  international  coalition  partners  and  commercial  entities.  This 
actionable  intelligence  is  the  cornerstone  of  successful  counterterrorist  and  maritime  law 
enforcement  operations  and  is  critical  to  Maritime  Security  [Morgan  and  Wiinmer,  2005]. 

The  U.S.  Navy,  as  a  partner  in  the  development  and  creation  of  MDA,  has  tasked 
its  subordinate  commands  to  identify  and  define  capabilities  to  support  this  program.  One 
effort  sponsored  is  the  Comprehensive  Maritime  Awareness  (CMA)  Joint  Capabilities 
Technology  Demonstration  (JCTD)  [CMA  Architecture  Team,  2007].  This  project 
supports  the  CMA  JCTD  efforts  by  proposing  a  deployable  system  to  enable  a 
disconnected  vessel  to  connect  to  the  CMA  network.  A  disconnected  user  can  be  seen  as 
a  merchant  ship,  hospital  ship  or  any  vessel  that  is  not  currently  connected  to  the  CMA 
network.  This  project’s  proposed  deployable  system,  as  a  subset  to  the  CMA  network, 
facilitates  information  sharing  in  support  of  humanitarian  efforts  worldwide. 
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EXECUTIVE  SUMMARY 


After  the  attacks  of  9/11,  increased  security  became  a  national  priority  that 
resulted  in  a  focus  on  National  Maritime  Security.  Maritime  Domain  Awareness  is  an 
initiative  developed  by  the  Coast  Guard,  to  increase  awareness  of  activities  in  the 
maritime  domain  in  support  of  maritime  security  [Morgan  and  Wimmer,  2005],  The 
purpose  of  MDA  is  to  generate  actionable  intelligence  obtained  via  the  collection,  fusion 
and  dissemination  of  infonnation  from  United  States  (U.S.)  joint  forces,  U.S.  government 
agencies,  international  coalition  partners  and  commercial  entities.  This  actionable 
intelligence  is  viewed  as  the  cornerstone  of  successful  counterterrorist  and  maritime  law 
enforcement  operations  and  is  critical  to  Maritime  Security  [Morgan  and  Wimmer,  2005]. 

The  U.S.  Navy  has  tasked  its  subordinate  commands  to  identify  and  define 
capabilities  to  support  this  program.  One  such  effort  is  the  Comprehensive  Maritime 
Awareness  (CMA)  Joint  Capabilities  Technology  Demonstration  (JCTD)  [CMA 
Architecture  Team,  2007]. 

This  extending  Comprehensive  Maritime  Awareness  (xCMA)  project  augments 
the  CMA  JCTD  by  addressing  the  requirements  and  functions  required  to  connect  the 
user  vessel  into  the  CMA  network.  These  vessels  will  hereafter  be  referred  to  as 
disconnected  vessels,  or  Node  5’s,  where  detailed  definitions  of  Node  5’s  will  follow  in 
this  report. 

Using  a  tailored  system  engineering  process,  identified  in  detail  in  the  following 
report,  system  alternatives  were  developed  and  evaluated  based  on  stakeholder  defined 
key  system  parameters.  Four  primary  alternatives  were  recommended  and  evaluated 
based  on  reliability  and  throughput  simulations  resulting  in  a  recommendation. 

The  resulting  recommendation  indicates  all  four  options  are  viable  systems  and 
are  capable  of  providing  a  solution  to  the  problem;  however,  as  this  report  shows,  the 
Satellite  Communication  (SATCOM)  with  a  Single  Board  Computer  (SBC)  alternative,  is 
the  higher  ranked  configuration  for  extending  CMA  to  a  disconnected  node  in  support  of 
humanitarian  efforts.  In  this  approach,  a  SATCOM  capability  is  used  as  the 
communications  means  for  connecting  to  the  CMA  network.  The  information  from  the 

xiii 


host  system  consisting  of  an  SBC,  modem/router,  power  supply,  display,  and  input 
devices  packaged  in  a  ruggedized,  transportable  container  is  routed  through  the 
modulator  demodulator  (modem)  and  then  transmitted  by  the  satellite  transmitter  to  the 
Node  4  satellite  receiver  (Node  4  details  are  to  follow).  The  information  from  Node  4  is 
transmitted  by  a  satellite  transmitter  and  received  by  the  system  satellite  receiver  and 
demodulated  for  processing  by  the  host  system.  The  Network  Interface  Card  (NIC) 
provides  the  system  with  a  unique  hardware  Media  Access  Control  (MAC)  address  for 
system  identification.  A  Commercial-Off-The-Shelf  (COTS)  Global  Positioning  System 
(GPS)  receiver  is  used  to  provide  system  Position  Location  Information  (PLI).  This 
recommendation  provides  a  solution  to  enable  the  connection  of  a  disconnected  vessel  to 
the  CMA  network. 
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I.  INTRODUCTION 


The  evolving  need  for  distributed  information  in  support  of  national  maritime 
security  policies  has  given  rise  to  the  concept  of  Maritime  Domain  Awareness  (MDA). 
The  need  for  distributed  information  has  been  addressed  at  the  National,  Department  of 
Defense  and  U.S.  Navy  levels.  A  Joint  Capabilities  Technology  Demonstration  (JCTD) 
effort  titled  Comprehensive  Maritime  Awareness  (CMA)  began  in  2006  and  intends  to 
improve  MDA  through  the  demonstration  of  interagency  and  international  information 
exchange.  The  focus  of  this  engineering  study  is  to  augment  the  CMA  JCTD  efforts  by 
defining  the  functional  requirements,  architecture,  and  systems  required  to  extend  CMA 
to  disconnected  users  and  vessels.  The  results  include  a  recommendation  based  on  the 
evaluation  performed  using  a  tailored  systems  engineering  development  processes. 


A.  BACKGROUND 

MDA  is  an  initiative  developed  by  the  Coast  Guard,  in  partnership  with  the  U.S. 
Navy  and  other  agencies  to  increase  awareness  of  activities  in  the  maritime  domain  in 
support  of  maritime  security  [Morgan  and  Wiinmer,  2005],  It  evolved  as  a  result  of  the 
threat  and  security  challenges  incurred  in  the  Post  9/11  Era  and  was  mandated  by 
President  George  W.  Bush  in  2004  [White  House,  2004], 

The  purpose  of  MDA  is  to  generate  actionable  intelligence  obtained  via  the 
collection,  fusion,  and  dissemination  of  information  from  U.S.  joint  forces,  U.S. 
government  agencies,  international  coalition  partners  and  commercial  entities.  This 
actionable  intelligence  is  viewed  as  the  cornerstone  of  successful  counterterrorist  and 
maritime  law  enforcement  operations  and  is  critical  to  Maritime  Security  [Morgan  and 
Wiinmer,  2005], 

MDA  is  the  result  of  the  proper  integration  of  a  diverse  set  of  capabilities,  which 
provide  decision  makers  with  an  effective  understanding  of  the  maritime  domain.  This 
effective  understanding  supports  the  decision  making  process  and  facilitates  operational 
response.  Achieving  MDA  depends  on  the  ability  to  persistently  monitor  the  four  MDA 
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pillars  (vessels,  cargo,  personnel  and  infrastructure),  and  scrutinize  activities  in  day-to- 
day  operations  in  such  a  way  that  trends  and  anomalies  can  be  identified. 

The  CMA  JCTD  intends  to  demonstrate  the  effective  and  efficient  use  of  data 
management  strategies  and  automated  tools.  The  goals  of  the  CMA  JCTD  are  to  address 
the  identified  gaps  with  effective  and  efficient  prioritization  of  maritime  threats  and  to 
enable  proper  allocation  of  security  resources  in  the  maritime  environment.  Residuals  of 
the  CMA  JCTD  include,  but  are  not  limited  to,  an  architectural  structure,  concept  of 
operations,  core  collaborative  toolsets  and  technology  evaluation. 

A  gap  in  this  implementation  is  the  capability  to  connect  a  non-CMA  vessel  or 
entity  to  the  CMA  environment.  This  capability  gap  is  the  focus  of  this  project  effort, 
which  defines  the  architecture,  system  requirements,  and  effort  needed  to  facilitate  the 
extension  of  CMA  (xCMA)  to  disconnected  vessels  and  users.  The  effort  addresses  the 
capabilities  and  capacities  required  to  provide  timely  and  accurate  maritime  situational 
awareness,  in  the  form  of  their  User  Defined  Awareness  Picture  (UDAP),  to  the 
disconnected  nodes. 

B.  PROBLEM  STATEMENT 

The  Chief  of  Naval  Operations  (CNO)  noted  that  the  navies  are  not  only 
important  in  the  execution  of  operations  in  support  of  wartime  efforts,  but  are  also 
“instruments  of  peace”  and  stressed  the  need  for  a  global  network  of  maritime  nations. 
This  network  provides  a  collective  response  to  all  participants  enabling  a  global 
perspective  of  the  maritime  domain  that  is  essential  for  national  security,  global  stability, 
and  economic  prosperity  [Green,  2007]. 

This  global  network  does  not  currently  exist  and  addressing  a  suitable  network  is 
the  primary  goal  of  the  CMA  JCTD  currently  ongoing  under  the  direction  of  Program 
Executive  Officer,  Command,  Control,  Communications,  Computers,  Intelligence  (PEO- 
C4I).  This  thesis  augments  the  work  being  completed  by  the  CMA  activities  to  facilitate 
continued  information  sharing.  The  specific  focus  is  on  the  evaluation  of  the  CMA 
architecture  and  the  identification  of  modifications  and  systems  required  to  ensure  that 
disconnected  vessels  are  active  participants  in  CMA. 
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c. 


KEY  TERMS  AND  DEFINITIONS 


The  definition  of  key  terms  is  essential  to  understanding  the  scope  of  this  effort. 
The  intent  of  the  following  paragraphs  is  to  identify  these  definitions  as  they  pertain  to 
this  effort. 

1.  Comprehensive  Maritime  Awareness 

CMA  is  an  MDA  implementation  with  a  goal  of  addressing  serious  gaps  in  the 
ability  to  identify  and  prioritize  maritime  threats.  The  CMA  architecture  consists  of  three 
categories  of  nodes:  user,  operational,  and  enterprise.  The  CMA  efforts  have  been 
focused  on  the  requirements  and  implementation  of  the  operational  and  enterprise  nodes, 
depicted  in  the  Operational  View  (OV-1)  as  Nodes  1-4,  as  shown  in  Figure  1.  The  user 
node,  Node  5,  has  had  limited  evaluation  to  date  and  is  being  addressed  by  this  thesis  to 
augment  the  parallel  efforts  of  the  CMA  JCTD. 


Figure  1.  Comprehensive  Maritime  Awareness  Operational  View  (OV-1). 

Source:  CMA  JCTD  Interim  Report  on  Architecture  draft  version  0.2  (2007)  by  David  R. 
Reading  [Reading,  2007].  This  OV-1  provides  a  pictorial  representation  of  the 
connections  and  node  interactions  as  referenced  in  the  CMA  Architecture. 

Nodes  1  and  2  are  the  primary  and  secondary  nodes,  with  Node  1  functioning  as 
the  central  repository,  and  Node  2  as  the  replication  backup.  Nodes  3  and  4  are  regional 
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nodes,  with  Node  3’s  functioning  as  the  geographically  defined  regional  gateways  and 
Node  4’s  as  the  sectional/functional  gateways.  The  last  node  is  the  user  node,  which  is 
identified  as  Node  5.  The  task  of  this  thesis  is  to  evaluate  the  effort  needed  to  extend  the 
CMA  architecture  to  a  disconnected  Node  5. 

The  Node  Connectivity  (OV-2),  as  shown  in  figure  2,  is  a  graphical  representation 
of  the  relationship  between  the  various  CMA  nodes.  The  primary  focus  for  this 
engineering  study,  as  indicated  by  the  circle  on  figure  2,  is  in  the  relationship  between  the 
disconnected  Node  5  and  the  existing  Node  4.  This  narrows  the  focus  and  identifies  the 
functional  requirements  and  capabilities  for  a  Node  5  vessel  or  user  to  be  able  to 
collaborate,  define  local  UDAP,  assess  threats  and  submit  maritime  data/information  to 
the  Node  4  Gateway. 


i  l  i 

A  ■  ■  , 

Enterprise 

Data 

Sources 


Figure  2.  CMA  Node  Connectivity  Diagram  (OV-2). 

Source:  CMA  JCTD  Interim  Report  on  Architecture  draft  version  0.2  (2007)  by  David  R. 
Reading  [Reading,  2007].  This  figure  depicts  an  abstract  model  of  the  CMA  nodes.  The 
circle  on  the  figure  identifies  the  primary  focus  of  this  thesis  as  the  relationship  between 
the  disconnected  Node  5  and  existing  Node  4  interaction. 
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2.  Node  4 

A  Node  4  participant  is  the  gateway  between  the  Node  5  entity  and  the  CMA 
network.  It  provides  connectivity  between  Node  5  and  all  other  CMA  nodes.  Node  4  is 
capable  of: 

•  Collecting  CMA  data,  including  data  from  Node  5  and  providing  it  to  the 
CMA  network 

•  Fusing  CMA  and  Node  5  maritime  data/info,  using  existing  CMA  fusion 
capabilities 

•  Assessing  threats;  alerts 

•  Sharing  threats  &  pictures;  including  providing  the  UDAP  for  Node  5 

3.  Node  5 

A  Node  5  participant  is  a  disconnected  user  or  vessel  that  does  not  have  direct 
connection  to  the  existing  CMA  network.  There  is  no  data  fusion  capability  at  Node  5. 
This  node  is  limited  to  sending  request  for  area  information  and  receiving  updates  from 
Node  4.  The  key  functional  areas  addressed  by  a  Node  5  entity  include: 

•  Limited  sensor  data  manually  entered  at  an  aperiodic  rate 

•  Provides  input  into  CMA  network  via  Node  4  connection 

•  Receives  guidance  from  CMA  network  regarding  mission  specific 
information  via  Node  4 

D.  ASSUMPTIONS 

The  following  are  the  high  level  assumptions  made  during  this  evaluation  effort. 

•  CMA  exists,  policies  and  restrictions  are  in  place,  and  Nodes  1  through  4 
are  implemented  and  fully  operational. 

•  Node  4  has  fusion  and  operational  capabilities  to  enable  disadvantaged 
node  connection  to  the  CMA. 

•  The  architecture  is  an  open  design  to  accommodate  integration  of  other 
systems. 
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•  Technology  and  policy  for  information  sharing,  e.g.,  Multi-Level  Security 
(MLS)  and  UDAP,  exist  and  are  implemented. 

E.  OBJECTIVES 

The  direction  provided  by  the  primary  stakeholders  in  the  form  of  a  Statement  of 
Work  (SOW),  encompasses  four  primary  objectives:  (1)  Characterization  of  the  Problem 
Space,  (2)  Functional  Representation  and  Decomposition,  (3)  Analysis  of  Key 
Capabilities,  and  (4)  Documentation.  The  specifics  of  each  of  these  areas,  as  defined  by 
the  SOW,  are  as  follows: 

1.  Characterization  of  the  Problem  Space:  identify  current  system  and  legacy 
deficiencies  as  well  as  constraints  inherent  in  the  operational  environment  in  order 
to  characterize,  understand  and  bound  the  problem  space.  The  project  team 
identifies  and  translates  the  relevant  CMA  functions  from  the  Fleet  MDA  Concept 
of  Operations  (CONOPS),  National  MDA  CONOPS,  and  the  CMA  CONOPS 
into  system  engineering  structures  (“to  be”  concepts,  data  models,  and 
architecture  functions,  requirements,  solutions)  necessary  to  develop  the 
disconnected  Node  5  concept.  The  project  team  evaluates  the  functions, 
requirements  and  architectures  in  support  of  the  integration  of  CMA 
requirements. 

2.  Functional  Representation  And  Decomposition:  represent  the  system  concepts 
through  functional  description  and  decomposition  as  well  as  system  architecting 
and  simulation.  Develop  representations,  models,  and  methods  to  express 
automated  resource  collaboration  concepts  and  information  sharing  solutions  in 
the  context  of  the  CMA  architecture  and  domains.  The  project  team  will  develop  a 
system  model  and  architecture  to  evaluate  the  perfonnance  of  the  proposed 
architecture.  System  architectures  are  organized  into  views  consistent  with  the 
Department  of  Defense  Architecture  Framework  (DoDAF). 
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3.  Analysis  of  Key  Capabilities:  the  identification  and  evaluation  of  technologies 
and  research  areas  is  key  to  the  integration  of  Node  5  into  the  CMA  concept. 

4.  Documentation: 

a.  PROJECT  REPORT  -  Includes  Chapters  1-5  detailing  the  problem 
statement,  needs  analysis  and  requirements  definition,  value  system 
design,  design  and  analysis  and  recommendations. 

b.  IN  PROGRESS  REVIEW  (IPR)  -  Status  review  provided  end  of 
Quarter  2. 

c.  FINAL  PRESENTATION 

F.  THESIS  SUMMARY 

In  the  past  three  years,  the  concept  of  MDA  has  evolved  from  the  idea  generated 
in  the  form  of  a  presidential  directive,  to  Concept  of  Operations,  to  the  inception  of  a 
technology  demonstration.  There  are  several  documents  and  plans  that  have  been  written 
detailing  the  requirements,  operational  impacts  and  draft  architecture.  One  area 
overlooked  to  date  is  the  introduction  of  a  non-CMA,  disconnected  vessel,  i.e.  a  hospital 
ship  or  shipping  vessel,  into  the  MDA  environment  and  enable  it  to  be  an  active 
participant  in  the  infonnation  exchange.  This  is  the  focus  of  the  thesis,  the  extension  of 
CMA  to  disconnected  users  or  vessels. 

The  basis  for  the  processes  implemented  in  the  evaluation  of  this  engineering  task 
is  a  tailored  systems  engineering  design  process.  This  process  was  tailored  to  address  the 
efforts  required  to  perform  the  analysis  and  evaluation  of  the  extended  CMA  (xCMA) 
project.  The  tailored  process  is  shown  in  Figure  3.  As  depicted  by  the  process  flow, 
there  are  four  main  phases  encompassing  the  engineering  cycle;  Needs  Analysis  & 
Requirements  Definition,  Value  System  Design,  Design  and  Analysis,  and  Decision 
Making. 
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Figure  3.  xCMA  Engineering  Process.  This  figure  depicts  the  tailored  systems 
engineering  process  used  in  this  effort  as  well  as  the  flow  of  this  report. 


These  engineering  processes  provide  guidance  and  facilitate  the  engineering 
activities  necessary  to  define  the  problem,  perform  design  and  analysis  and  support 
decision  making.  These  efforts  culminate  in  an  analysis  of  alternatives  and  a 
recommendation  focused  on  the  extension  of  CMA  to  a  disconnected  vessel. 

The  resulting  recommendation  indicates  the  Satellite  Communications 
(SATCOM)-Single  Board  Computer  (SBC)  Alternative,  as  the  preferred  option  for 
extending  CMA  to  a  disconnected  node  in  support  of  humanitarian  efforts.  A  satellite 
communications  capability  is  used  as  the  communications  means  for  connecting  to  the 
CMA  network.  The  information  from  the  host  system  consisting  of  an  SBC, 
modem/router,  power  supply,  display,  and  input  devices  packaged  in  a  ruggedized, 
transportable  container  is  routed  through  the  modulator  demodulator  (modem)  and  then 
transmitted  by  the  satellite  transmitter  to  the  Node  4  satellite  receiver.  The  information 
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from  Node  4  is  transmitted  by  a  satellite  transmitter  and  received  by  the  system  satellite 
receiver  and  demodulated  for  processing  by  the  host  system  Mobile  Tenninal  Equipment 
(MTE).  The  Network  Interface  Card  (NIC)  provides  the  system  with  a  unique  hardware 
Media  Access  Control  (MAC)  address  for  system  identification.  A  Commercial-Off- 
The-Shelf  (COTS)  Global  Positioning  System  (GPS)  receiver  is  used  to  provide  system 
Position  Location  Information  (PLI). 


9 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


10 


II.  NEEDS  ANALYSIS  AND  REQUIREMENTS  DEFINITION 


The  first  phase  of  the  systems  engineering  process  is  the  problem  definition  phase 
consisting  of  needs  analysis  and  requirements  definition.  These  efforts  include  literature 
review  and  stakeholder  analyses  and  result  in  the  generation  of  system  level  requirements 
consisting  of  derived  and  stakeholder  requirements.  See  Figure  4  for  a  detailed 
illustration.  The  purpose  of  these  activities  are  to  accurately  identify  the  problem, 
understand  what  the  user  wants  and  define  value  rankings  of  the  system  based  on  the  user 
inputs.  The  problem  definition  phase  begins  with  a  primitive  need  statement.  For  this 
effort,  the  primitive  need  was  derived  from  a  combination  of  the  Statement  of  Work  and 
direction  received  from  the  stakeholders.  The  primitive  need  statement  is  as  follows: 

‘To  facilitate  Maritime  Domain  Awareness,  disconnected  nodes  need  to  be 
integrated  into  the  Comprehensive  Maritime  Awareness  construct  to  share  data 
in  support  of  humanitarian  operations 
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Figure  4.  Needs  Analysis  and  Requirements  Definition  Phase. 

The  green  square  in  the  figure  indicates  the  current  position  in  the  tailored  engineering 
process. 


A.  LITERATURE  REVIEW 

In  order  to  ensure  a  clear  understanding  of  the  problem  and  the  evolution  of 
MDA,  an  extensive  literature  search  was  required.  This  literature  search  includes,  but  was 
not  limited  to,  information  relating  to  MDA  and  CMA.  The  tight  coupling  of  this 
engineering  task,  with  the  on-going  CMA  efforts,  resulted  in  stakeholder  identification  of 
the  key  documents  pertaining  to  CMA.  This  chapter  identifies  the  evolution  of  the 
documents,  provides  a  summary  of  each  document  and  details  the  accomplishments  and 
capability  gaps. 

President  George  W.  Bush’s  2004  presidential  directive  began  an  initiative  to 
increase  awareness  of  maritime  domain  activities.  Achieving  MDA  helps  ensure  national 
maritime  security  and  supports  an  open  global  economy,  which  depends  heavily  on 
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maritime  commerce.  To  maintain  operation  of  the  maritime  commerce  and  provide 
maritime  security,  “MDA  depends  upon  unparalleled  information  sharing”  [United  States 
Department  of  Homeland  Security,  2005], 

MDA  has  evolved  and  been  shaped  by  documents  generated  at  the  National, 
Department  of  Defense  and  the  U.S.  Navy  levels.  These  documents  represent  the  work 
products  and  activities  that  have  immediate  impact  on  the  U.S.  Navy’s  effort  to  achieve 
MDA  and  include  the  National  MDA  CONOPS,  Navy  MDA  Concept,  Fleet  MDA 
CONOPS,  Navy  MDA  Architecture,  Maritime  Headquarters  (MHQ)  with  Maritime 
Operations  Center  (MOC),  CMA  CONOPS  and  the  CMA  JCTD  -  Interim  Report  on 
Architecture.  The  interrelationships  between  these  documents  are  illustrated  in  Figure  5. 

The  initial  efforts  in  defining  MDA  are  contained  in  two  presidential  directives, 
the  National  Security  Presidential  Directive  (NSPD)  41  and  the  Homeland  Security 
Presidential  Directive  (HSPD)  13.  Since  their  creation,  there  have  been  several  activities 
at  the  National  and  Department  of  Defense  (DOD)  levels  initiating  U.S.  Navy  efforts  in 
MDA.  The  U.S.  Navy’s  activities  and  work  products  were  derived  or  influenced  by 
visions,  strategies,  and  plans  from  the  National  and  DOD  levels. 

The  National  Policy  HSPD  14  generated  the  National  Strategy  for  Maritime 
Security.  From  this  directive,  the  National  Plan  to  Achieve  MDA  and  the  National  MDA 
CONOPS  were  generated.  The  National  MDA  CONOPS  further  drilled  into  the 
implementation  perspective  and  eventually  created  the  MDA  Information  Technology 
Investment  Strategy  Capabilities  Based  Assessment  (CBA)  Process  [United  States  Navy, 
2007]. 
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Figure  5.  U.S.  Navy  Development  Flow. 

This  figure  shows  the  relationship  between  the  U.S.  Navy  MDA  documents.  The  dashed 
lines  indicate  the  influential  sources  and  the  solid  lines  identify  the  originating 
documents.  The  yellow  boxes  represent  the  national  documents.  The  blue  boxes 
represent  the  U.S.  Navy  documents.  The  purple  boxes  represent  the  joint  documents. 


The  definition  of  MDA  is  “the  effective  understanding  of  anything  associated 
with  the  global  maritime  domain  that  could  impact  the  security,  safety,  economy,  or 
environment”  [United  States  Department  of  Homeland  Security,  2005].  The  maritime 
domain  is  defined  as  “all  areas  and  things  of,  on,  under,  relating  to,  adjacent  to,  or 
bordering  on  a  sea,  ocean  or  other  navigable  waterway,  including  all  maritime-related 
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activities,  infrastructure,  people,  cargo,  and  vessels  and  other  conveyances”  [United 
States  Department  of  Homeland  Security,  2005]. 

At  the  DOD  level,  there  are  two  primary  documents,  the  Homeland  Security, 
Major  Combat  Operation  and  Stability  Deterrence  and  the  National  Command  Element 
Protection.  These  documents  were  created  by  the  Joint  Operations  Center  (JOC)  and  the 
Joint  Forces  Command  (JFC)  [United  States  Navy,  2007]. 

With  the  visions,  strategies,  and  plans  from  the  National  and  DOD  levels,  the  U.S. 
Navy  has  developed  several  documents  that  include  the  Navy  Maritime  Strategy,  Navy 
Operations  Concept,  Navy  MDA  Concept,  Fleet  MDA  CONOPS,  Navy  MDA 
Architecture,  Capabilities  Based  Analysis  Process,  Navy  MDA  Investment  Strategy,  and 
Navy  War  Fighting  Capabilities  [United  States  Navy,  2007].  In  addition,  the  CMA  JCTD 
documents  resulting  from  the  technology  demonstration  efforts  provided  clarifying 
information  to  the  Fleet  MDA  CONOPS. 

A  synopsis  of  the  core  documents  and  the  key  infonnation  they  contain  are 
detailed  below. 

1.  Navy  MDA  Concept 

The  NSPD  41  /  HSPD  (late  2004)  directed  the  creation  of  the  Maritime  Security 
Policy  Coordinating  Committee  (MSPCC)  to  oversee  the  development  of  the  National 
Strategy  for  Maritime  Security  (NSMS).  The  MSPCC  established  the  MDA 
Implementation  Team  to  develop  an  interagency  concept  of  operations  and  an 
interagency  investment  strategy.  The  conclusions  are  as  follows; 

•  Homeland  security  was  heavily  focused  on  internal  U.S.  government 
information  and  intelligence  sharing 

•  An  international  and  interagency  framework  for  maritime  security 
would  be  required 

•  The  U.S.  Navy  must  play  a  key  role 
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The  U.S.  Navy  MDA  Concept  recognized  that  achieving  MDA  requires 
collaboration  among  the  different  stakeholders.  The  U.S.  recognized  that  achieving 
MDA  requires  an  understanding  of  our  international  partners.  That  is,  the  U.S.  must 
understand  and  acknowledge  that  international  partners  are  focused  on  how  to  support 
legal  activities,  such  as  freedom  of  the  seas,  domestic  /  commercial  security,  energy 
security,  and  fisheries,  as  well  as  how  to  deter  illegal  activities,  such  as  narco-trafficking, 
illegal  immigration,  piracy,  smuggling,  and  environmental  damage.  On  the  home  front,  it 
must  be  recognized  that  both  private  sector  and  all  levels  of  government  agencies  play  an 
important  role  in  the  success  of  MDA.  Supporting  the  needs  and  roles  of  each 
stakeholder  allows  all  interested  parties  to  work  toward  common  objectives  that  foster  a 
culture  of  trust  and  confidence  to  achieve  MDA. 

The  Navy  MDA  Concept  identified  gaps  that  the  U.S.  Navy  must  fill  both 
internally  and  internationally.  Internally,  it  is  recognized  that  the  U.S.  Navy  has  limited 
capability  in  the  collection  and  fusion  of  data.  It  is  also  recognized  that  the  U.S.  Navy 
only  has  a  common  operating  picture  at  a  localized,  classified,  tactical  level  and  has  a 
limited  capability  to  develop  a  coherent  picture  of  small  craft  in  the  littoral  area  of 
interest.  Internationally,  the  U.S.  Navy  recognizes  it  must  also  address  the  shortcomings 
that  prevent  the  collection  and  sharing  of  information  across  boundaries. 

The  Federal  Aviation  Administration  (FAA)  /  North  American  Aerospace 
Defense  Command  (NORAD)  model  is  identified  as  a  good  case  to  help  establish  safety 
of  flight  and  effect  commercial  efficiency  across  the  world.  There  are  two  key  attributes 
of  this  model  that  are  of  interest  to  the  Navy  MDA  Concept; 

•  The  FAA/NORAD  process  is  unclassified,  which  allows  the  sharing  of 
information  freely  across  boundaries 

•  The  FAA/NORAD  model  is  not  controlled  by  DOD 

The  model  seeks  support  and  collaboration  from  DOD,  which  allows  common 
goals  to  be  accomplished  while  increasing  the  model’s  capacity.  The  Navy  MDA 
Concept  relies  on  the  FAA/NORAD  model  to  help  translate  MDA  requirements  into 
reality.  The  unclassified  data  and  information  collection,  correlation,  and  dissemination 
capability  and  capacity  of  the  collaborating  stakeholders  enables  the  free  flow  of 
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information  in  support  of  collective  security.  This  provides  a  strong  incentive  for 
additional  partners  to  join  in  the  MDA  effort  [United  States  Department  of  Homeland 
Security,  2007]. 

2.  National  MDA  CONOPS 

The  National  MDA  CONOPS  was  developed  to  execute  the  National  Plan  to 
Achieve  Maritime  Domain  Awareness.  The  goals  of  this  CONOPS  are  to  facilitate  the 
deterrence  and  prevention  of  hostile  or  illegal  acts  within  the  maritime  domain  and  to 
enhance  safety,  security,  economy  and  protect  the  environment.  To  accomplish  these 
goals,  the  CONOPS  created  the  following  objectives:  (1)  Describe  the  problem,  (2) 
Describe  the  interagency  desired  state  of  MDA,  (3)  Improve  MDA  planning  and 
execution  at  all  levels  and  (4)  Identify  MDA-related  functions  and  desired  MDA-related 
capabilities  [United  States  Navy,  2007]. 

The  scope  of  the  National  MDA  CONOPS  includes  the  stakeholders  from  the 
U.S.  Federal  Agencies  within  the  Global  Maritime  Community  of  Interest  (GMCOI), 
state  and  local  agencies,  private  sector  and  international  partners.  It  was  developed  to 
complement  existing  programs  and  initiatives  that  affect  the  maritime  security  and  it 
identified  key  components  for  achieving  MDA.  The  Global  Maritime  Intelligence  (GMI) 
and  Global  Maritime  Situational  Analysis  (GMSA)  are  identified  as  two  of  these  key 
components.  MDA  is  achieved  through  effective  and  efficient  integration  of  GMI  and 
GMSA  (MDA  =  GMI  +  GMSA).  To  do  so,  the  CONOPS  recognizes  the  importance  of 
the  following; 

•  Distinction  of  responsibilities  of  the  maritime  agencies  developing 
GMI  and  the  responsibilities  of  those  maritime  stakeholders  providing 
GMSA 

•  Interactive  qualities  of  GMI  and  GMSA  repeated  throughout  the 
CONOPS  to  emphasize  the  foundational  dependence  upon  this 
partnership 

•  Synergy  between  intelligence  and  situational  awareness 
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The  following  are  defined  in  response  to  the  CONOPS  objectives  in  an  effort  to 
meet  the  goals  listed  above. 


a.  Problem  Description: 

Intelligence  and  information  are  critical  to  the  success  of  MDA  and  must 
be  gathered  and  shared  across  numerous  boundaries  for  the  effective  understanding  of  the 
maritime  domain.  There  are  obstacles  that  impede  the  ability  to  share  intelligence  and 
information  that  are  necessary  to  achieve  MDA.  The  National  MDA  CONOPS  identifies 
these  obstacles  as  follows  [United  States  Navy,  2007]; 

•  Ineffective  database  connections  for  analysis  of  information  gaps  or 
redundancies 

•  Inability  to  create  situational  awareness  due  to  ineffective  area-target 
information  fusion 

•  Incompatible  and  proprietary  operating  systems  and  organizations 

•  Lack  of  trusted  partnerships  for  sharing  of  information  and  intelligence 

•  Policy  restrictions  on  sharing  data  due  to  organizational  perception 

•  Limited  interagency  communications,  connectivity,  and 
interoperability 

•  Limited  interagency  awareness  of  complementary  mission 


b.  Interagency  Desired  State  of  MDA 

The  National  MDA  CONOPS  envisions  “an  environment  where  federal, 
state,  local,  tribal,  private  sector  and  international  partners  embrace  and  achieve  the 
common  objective  of  obtaining  and  sharing  information  as  a  mechanism  to  increase 
safety,  security  and  economic  prosperity  in  the  maritime  domain  and  have  the  supporting 
architecture  to  do  so”  [United  States  Navy,  2007].  To  reach  this  desired  state,  the  MDA 
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environment  depends  on  the  ability  to  monitor  activities;  identify  and  detect  anomalies; 
collect,  fuse,  and  analyze  data  through  the  use  of  automated  fusion  and  analysis  tools.  It 
also  allows  the  operational  decision  makers  to  effectively  engage  and  defeat  anticipated 
threats  and  meet  the  MDA  Essential  Task  List  from  the  MDA  Plan. 


c.  Improve  MDA  Planning  and  Execution  [United  States  Navy, 
2007] 

The  National  MDA  CONOPS  addressed  the  processes  required  to  achieve 
the  desired  MDA  state.  These  processes  included  collection,  fusion,  analysis  and 
understanding  of  data,  dissemination,  and  archiving  and  maintaining  discoverable 
information.  Improving  planning  and  execution  in  order  to  achieve  the  desired  MDA 
state  at  all  levels  involves  the  implementation  and  adherence  to  these  processes.  The 
collection  process  involves  gathering  data  and  information  from  any  pertinent  source  and 
method  and  requires  cooperation  between  stakeholders  of  GMI  and  GMSA.  The  fusion 
process  was  defined  as  the  activity  of  association,  combination,  and  conversion  of  data  or 
information  into  useable  knowledge  for  the  decision  maker.  This  process  was  defined  as 
critical  when  data  or  information  examination  was  required  for  the  detection  of  activities 
of  interest  with  respect  to  operating  patterns,  anomalies,  capability,  and  intent.  The 
dissemination  process  was  defined  as  “providing  the  right  information  to  the  right  users” 
[United  States  Navy,  2007].  In  the  context  of  MDA,  the  dissemination  process  must 
provide  relevant  data,  products,  alerts,  and  warnings  to  the  decision  makers,  analysts,  and 
responders  within  the  GMCOI.  The  archival  and  maintenance  of  MDA  data  and 
information  was  identified  as  essential  for  an  effective  MDA.  Retention  and  retrieval  of 
historic  data  was  identified  as  a  critical  link  for  continuity  of  data  and  information  used 
for  enhanced  operational  capability. 

d.  Parsing  the  Domain  [United  States  Navy,  2007] 

The  National  Plan  to  Achieve  MDA  identified  a  requirement  to 
“persistently  monitor  vessels  and  craft,  cargo,  vessel  crews  and  passengers,  and  all 
identified  areas  of  interest  in  the  global  maritime  domain”  [United  States  Navy,  2007]. 
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This  desired  operational  state  identified  a  requirement  for  extensive  resources.  To 
maximize  the  limited  resources,  the  CONOPS  envisioned  an  ability  to  divide  and 
organize  the  maritime  domain  in  such  a  way  that  allowed  the  prioritization  of  assigned 
resources.  An  analysis  of  the  complete  supply  chain  of  events  was  identified  as  a  way  to 
gain  a  better  understanding  of  area  of  interest. 

e.  Levels  of  Awareness 

The  National  MDA  CONOPS  determined  the  prioritization  of  MDA 
capabilities  and  needs  required  parsing  the  MDA  domain  and  establishing  the  level  of 
awareness  for  each  Area  of  Interest  (AOI),  its  associated  processes,  and  its  subject 
category  [United  States  Navy,  2007].  The  levels  of  awareness  were  categorized  into 
general  (level  3),  specific  (level  2),  and  detailed  (level  1).  The  general  level  of  awareness 
contained  generalized  knowledge  of  patterns  of  migration,  travel,  and  work  in  the 
maritime  domain.  The  specific  level  of  awareness  included  specific  platforms,  their 
operators,  and  companies  working  in  the  area  of  interest.  The  detailed  level  of  awareness 
included  actual  information  at  an  individual  level.  This  covered  the  individual  passenger, 
crew,  and  worker  area  of  interest  [United  States  Navy,  2007]. 

f  Information  Architecture 

The  National  MDA  CONOPS  called  for  a  net-centric  architecture  robust 
enough  to  provide  the  required  environment  for  secure,  collaborative,  information¬ 
sharing.  The  CONOPS  envisioned  an  information  architecture  that  allowed  data 
providers  to  expose  data  for  consumers  to  locate  and  retrieve.  Furthennore,  the  data  was 
expected  to  flow  through  the  enterprise’s  multi-level  protocols  and  classifications  with 
automated  sanitization.  The  ultimate  desired  state  of  the  user  was  identified  as  the  ability 
to  create  a  User  Defined  Operational  Picture  (UDOP)  via  a  Services-Oriented 
Architecture  (SOA)  [United  States  Navy,  2007]. 
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3.  Concept  of  Operations  for  Fleet  Maritime  Domain  Awareness  (Fleet 
MDA  CONOPS) 

The  Fleet  MDA  CONOPS  was  developed  by  the  U.S.  Navy  and  approved  for  use 
on  13  March  2007  [United  States  Navy,  2007].  It  provided  a  foundation  for  the  U.S. 
Navy  commanders  to  build  and  achieve  MDA.  This  foundation  provided  the  necessary 
background  to  understand  the  fleet’s  role  in  MDA  and  how  it  related  to  other  entities 
including  the  U.S.  Navy  and  interagency  programs  and  directives.  The  Fleet  MDA 
CONOPS  focused  primarily  on  the  operational  level  of  warfare  [United  States  Navy, 
2007]. 

The  Fleet  MDA  CONOPS  defined  MDA  one  level  down  from  the  Navy  MDA 
Concepts  and  National  MDA  CONOPS,  integrated  standardized  MDA-related  processes 
and  mechanisms  into  Fleet  operations  and  guided  the  development  of  a  U.S.  Navy 
architecture  supporting  MDA.  This  Fleet  MDA  CONOPS  was  intended  to  help  the  U.S. 
Navy  in  fulfilling  its  roles  and  responsibilities  as  directed  in  the  National  Strategy  for 
Maritime  Security  and  its  supporting  plans”  [United  States  Navy,  2007]. 

The  Fleet  MDA  CONOPS  addressed  how  MDA  was  enabled  by  the  use  of 
maritime  intelligence  as  envisioned  by  the  Global  Maritime  Intelligence  Integration 
(GMII)  Plan  and  the  National  Strategy  for  Maritime  Security.  It  also  stated  that  effective 
decision  making  is  the  result  of  an  enabled  MDA  environment  in  accordance  with  the 
Maritime  Operational  Threat  Response  Plan  (MOTR)  and  in  support  of  all  U.S.  Navy 
missions”  [United  States  Navy,  2007]. 

The  primary  purpose  of  the  Fleet  MDA  CONOPS  was  to  provide  the  fleet  with  an 
understanding  of  MDA  and  to  describe  the  processes  and  mechanisms  that  enabled  the 
U.S.  Navy  to  accomplish  missions.  The  CONOPS  served  as  a  basis  for  future  U.S.  Navy 
capability  investment  decisions,  and  influenced  MDA  development  to  meet  current  and 
future  U.S.  Navy  needs.  The  following  sections  list  the  capability  gaps,  assumptions, 
restraints  and  constraints,  operating  environment,  MDA  fleet  deployment  and  tasks  and 
Doctrine,  Organization,  Training,  Materiel,  Leadership  and  Education,  Personnel,  and 
Facilities  (DOTMLPF)  items  identified  in  this  document. 
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a. 


Warfighting  Capability  Gaps 


The  following  user  inputs  were  used  to  derive  the  warfighting  capability 
gaps  [United  States  Navy,  2007]: 

•  Lack  of  net  assessment,  fusion,  and  collaboration  tools 

•  Lack  of  cross  domain  solutions  for  information  sharing 

•  Lack  of  maritime  information  gathering  and  collection  within  U.S. 
Navy  areas  of  interest 

•  Lack  of  communication  system  training 

b.  Assumptions  and  Constraints 

The  Fleet  MDA  CONOPS  addressed  the  assumptions,  restraints,  and 
constraints  to  ensure  that  there  was  an  understanding  within  the  U.S.  Navy  MDA 
organization.  The  assumptions  included  the  following  [United  States  Navy,  2007]: 

•  The  National  CONOPS  for  MDA  will  be  approved 

•  The  Navy  MDA  concept  will  be  approved 

•  MHQ  w/MOC  will  exist  as  the  principal  operational-level  command 
and  control  node  for  the  U.S.  Navy 

•  MHQ  w/MOC  will  be  the  primary  operational-level  net  assessment 
center  for  MDA  within  the  U.S.  Navy 

•  The  National  Maritime  Intelligence  Center  (NMIC)  will  serve  as  the 
Center  Of  Excellence  (COE)  for  all-source  maritime  intelligence 
fusion  within  the  GMCOI 

•  Technology  and  National  DOD  policy  for  infonnation  sharing,  e.g., 
MLS  and  UDOP,  will  be  developed  and  implemented  within  the 
Future  Years  Defense  Program  (FYDP)  to  support  fleet  information 
sharing  requirements 
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•  The  MDA  data  strategy  Community  Of  Interest  (COI)  will  develop 
common  data  standards  for  MDA  infonnation  to  be  shared  across 
multiple  security  levels  and  network  enclaves 

•  Engagement  with  US,  allied,  and  partner  nations,  Other  Government 
Agencies,  Non-Governmental  Organizations,  and  private  industry  is 
necessary  to  develop  MDA 

The  restraints  identified  the  scope  of  the  U.S.  Navy’s  contribution.  The 
U.S.  Navy  supported  initiatives  for  expanded  reporting  requirements  for  vessels  and 
cargo.  It  was  governed  by  maritime  strategy  and  was  limited  to  areas  where  naval  forces 
operate  [United  States  Navy,  2007]. 

The  constraints  included  the  focus  on  U.S.  Navy  capabilities  to  be  made 
available  within  Future  Year’s  Development  Program  (-2014).  The  Fleet  MDA 
CONOPS  identifies  U.S.  Navy  challenges  to  achieve  MDA.  These  challenges  included 
sharing  of  data  and  information  within  the  global  maritime  domain,  handling,  analyzing, 
releasing,  and  disseminating  data  from  multiple  sources,  operating  in  a  low  bandwidth 
environment,  and  adhering  to  different  laws,  policies,  regulations,  and  guidance  [United 
States  Navy,  2007]. 


c.  Operating  Environment 

The  Fleet  MDA  CONOPS  addressed  two  types  of  operational 
environments;  the  physical  setting  and  the  associated  infonnation  classification  layers. 
The  physical  setting  covered  the  U.S.  Navy’s  primary  operational  area,  “blue  water,”  and 
the  less  common  environments  such  as  “green  water”  (non-combatant  evacuation 
operations)  and,  “brown  water”  (riverine  operations)  [United  States  2007].  The 
information  classification  layers  identified  the  U.S.  Navy’s  focus  on  overcoming  the 
challenges  of  operating  in  an  environment  with  multiple  collaborators  and  different  levels 
of  security  access. 
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d. 


MDA  Capability  Deployment 


A  key  focus  of  the  Fleet  MDA  CONOPS  was  the  MDA  capability 
deployment.  The  CONOPS  identified  the  U.S.  Navy’s  contribution  at  three  levels;  (1) 
tactical,  (2)  operational,  and  (3)  strategic.  At  the  tactical  level,  the  U.S.  Navy  collected 
and  shared  information.  At  the  operational  level,  the  U.S.  Navy  participated  in  creating  a 
synergy  between  operations  and  intelligence  to  help  create  regional  maritime  situation 
awareness.  At  the  strategic  level,  the  Office  of  Naval  Intelligence  collaborated  with  the 
larger  GMCOI  Intelligence  Enterprise  to  develop  maritime  intelligence  and  threat 
awareness  [United  States  Navy,  2007].- 

The  CONOPS  identified  five  key  information  exchange  ingredients  for 
achieving  MDA.  These  ingredients  included:  Location  and  Tracking  Information, 
Contextual  Information,  Reference  Information,  Trend  Analysis,  and  Intelligence  [United 
States  Navy,  2007].  It  also  addressed  the  integration  of  MDA  requirements  into  existing 
or  future  systems  and  structures.  Two  key  initiatives,  Automatic  Identification  System 
(AIS)  and  Long  Range  Identification  and  Tracking  (LRIT)  system,  incorporated 
important  capabilities  into  the  MDA.  The  AIS  was  identified  as  a  maritime  transponder 
for  all  vessels  300  gross  tons  or  greater.  The  LRIT,  mandated  by  the  International 
Maritime  Organization  as  part  of  the  Safety  of  Life  at  Sea  Convention,  was  identified  as  a 
requirement  to  provide  the  ship’s  identity  and  time  stamped  location  [United  States  Navy, 
2007], 


e.  Fleet  MDA  Tasks 

To  address  the  fleet  MDA  requirements,  the  Fleet  MDA  CONOPS  derived 
a  set  of  twelve  tasks  from  the  Universal  Navy  Task  List.  These  tasks  were  applicable  to 
the  commanders  at  the  strategic,  operational,  and  tactical  levels.  The  derived  tasks  were 
identified  as  follows  [United  States  Navy,  2007]: 

•  Direct  operational  intelligence  activities 

•  Process  and  exploit  collected  operational  information 
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•  Produce  operational  intelligence  and  prepare  intelligence  products 

•  Disseminate  and  integrate  operational  intelligence 

•  Evaluate  intelligence  activities  in  the  joint  operations  area  (JOA) 

•  Assess  the  operational  situation 

•  Develop  a  shared  understanding  of  the  situation 

•  Acquire  and  communicate  operational-level  information  and  status 

•  Collect  and  share  operational  information 

•  Prepare  plans  and  orders 

•  Command  subordinate  operational  forces 

•  Coordinate  and  integrate  joint/multinational  and  interagency 
cooperation 

Along  with  the  twelve  tasks,  the  Fleet  MDA  CONOPS  identified  the 
responsible  entities  at  each  of  the  requirement  levels.  At  the  strategic  level,  NMIC  was 
identified  as  responsible  for  conducting  maritime  intelligence  activities,  integrating  and 
fusing  enterprise  intelligence,  supporting  the  operational  and  tactical  requirements  in  the 
maritime  domain.  At  the  operational  level,  the  MHQ  was  identified  as  responsible  for 
directing  the  operational  intelligence  activities  and  commanding  assigned  forces.  The 
activities  included  “indications  and  warning,  situational  awareness,  target  development, 
collection  management,  all-source  threat  analysis,  and  assessment  reporting  for 
operational  planning  and  execution”  [United  States  Navy,  2007].  At  the  tactical  level, 
Commander  Task  Forces,  Commander  Task  Groups,  and  Commander  Task  Units  were 
identified  as  responsible  for  directing  the  tactical  and  operational  intelligence  activities 
specific  to  mission  and  operations.  The  tasks  included  classification,  identification,  and 
engagement  areas  [United  States  Navy,  2007]. 

Along  with  the  fleet  MDA  tasks  and  responsible  entities,  the  Fleet  MDA 
CONOPS  identified  “processes”  as  a  key  ingredient  necessary  for  successful  operational 
intelligence  activities  for  MDA.  The  processes  used  in  the  MDA  life  cycle  include  five 
phases  [United  States  Navy,  2007]: 

•  Intelligence  planning  and  direction 

•  Collection 
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•  Processing/Exploitation,  i.e.,  process  and  exploit  collected  operational 
information 

•  Analysis/Production/Dissemination,  i.e.,  produce  operational  intelligence 
and  prepare  intelligence  products 

•  Assessment/Feedback,  i.e.,  evaluate  intelligence  activities  in  the  JOA 

These  phases  are  the  foundation  for  day-to-day  activities  which  ensures 
the  maritime  planning  process  mirrors  the  joint  planning  process,  develops  the  MHQ 
commander’s  intent,  turns  it  into  an  executable  plan,  and  tasks  tactical  forces. 

f.  Validation  Requirements 

To  address  the  validity  of  the  MDA  requirements,  experiments,  exercises, 
modeling  and  simulation  (M&S),  war  gaming,  workshops,  seminars,  and  rock  drills  have 
been  identified.  To  effectively  prepare  and  conduct  any  requirements  validation,  the 
Fleet  MDA  CONOPS  identified  analytical  questions  that  needed  to  be  asked  in  order  to 
gain  relevant  measures  of  effectiveness.  Along  with  the  analytical  questions,  the 
CONOPS  also  identified  an  analysis  plan  focused  on  workshops,  wargames,  and 
exercises.  To  effectively  measure  the  analysis,  the  CONOPS  identified  Measures  of 
Effectiveness  (MOE)  and  Measures  of  Performance  (MOP).  In  addition  to  the  MOEs  and 
MOPs,  an  Experimental  Campaign  Plan  (ECP)  was  developed  to  help  guide  the 
requirements  validation  [United  States  Navy,  2007]. 

4.  DOTMLPF 

The  Fleet  MDA  CONOPS  also  addressed  the  DOTMLPF  implications.  Under 
doctrine,  due  to  the  nature  of  MDA,  the  CONOPS  identified  a  shift  from  an  individual  to 
an  integrated  operational  environment.  This  requires  a  development  of  doctrine  and 
policy  that  includes: 

•  Roles,  Mission,  and  the  GMSA  task 

•  Enterprise  hubs 
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•  Information  sharing  policies 

•  Protocols  with  non-DOD  partners 

•  Revised  foreign  disclosure  policies  to  facilitate  the  time  sensitive  nature  of 
maritime  areas  of  interest 

For  the  organizational  focus,  policies  were  required  to  help  define  and  facilitate 
the  inter-agency  relationship  among  the  members  of  the  GMCOI.  These  included 
stakeholders  at  the  local,  state,  regional,  national,  and  international  levels.  For  training, 
the  CONOPS  called  for  effective  and  efficient  training  at  all  levels  which  included 
individual  skills,  unit  and  composite  group  training.  The  training  was  identified  to 
include  live,  virtual  environment  that  involves  real-world  complexity  in  against  a  range 
of  postulated  threats.  For  the  materiel  solutions,  alternatives  are  addressed  to  ensure 
effective  future  analysis.  For  the  leadership  area,  the  CONOPS  identified  a  requirement 
to  bring  all  stakeholders  together  to  ensure  trust,  confidence,  effective  and  efficient 
training,  and  lessons  learned.  For  personnel,  a  detailed  manpower  assessment  was 
required  to  effectively  implement  the  Fleet  MDA  CONOPS.  The  CONOPS  identified 
required  training  facilities  for  each  participating  organization.  The  CONOPS  identified 
that  there  were  no  common  operating  processes,  systems  or  linkages  to  the  GMSA 
enterprise  hubs.  Therefore,  each  participating  organization  must  use  existing  facilities  to 
satisfy  the  MDA  requirements  for  the  near  term  [United  States  Navy,  2007]. 


5.  CMA  JCTD  CONOPS 

The  CMA  JCTD  CONOPS  was  generated  under  the  efforts  of  the  CMA  JCTD 
which  was  focused  on  improvement  of  MDA  through  the  demonstration  of  interagency 
and  international  information  exchange.  The  goals  of  the  CONOPS  were  to  address  the 
identification  gaps  through  the  effective  and  efficient  prioritization  of  maritime  threats 
and  to  enable  proper  allocation  of  security  resources  in  the  maritime  environment. 

The  U.S.  Pacific  Command  (USPACOM)  and  Department  of  State  (DoS)  took 
steps  in  developing  a  multinational  maritime  security  framework  in  March  2004.  This 
collaboration  resulted  in  a  multilateral  maritime  security  framework  in  the  Asia-Pacific 
region.  This  effort  was  designed  to  offset  risks  posed  by  transnational  threats  including 
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“terrorism,  trafficking  in  humans  and  drugs,  movement  of  illicit  cargo,  and  piracy” 
[CMA  Architecture  Team,  2007].  Partnering  with  willing  nations  moves  the  participating 
stakeholders  toward  MDA  capability  “through  unity  of  effort  to  identify,  monitor,  and 
intercept  transnational  maritime  threats  consistent  with  existing  international  and 
domestic  laws”  [CMA  Architecture  Team,  2007]. 

To  move  one  step  closer  to  achieving  MDA  capability,  the  Republic  of  Singapore 
initiated  a  proposal  for  a  joint  effort  with  the  U.S.  to  establish  a  CMA  JCTD.  This  JCTD 
refines  the  goals  and  objectives  identified  in  the  National  Strategy  for  Maritime  Security, 
the  GMII  Plan,  and  the  NSPD  41  /  HSPD  13  Presidential  Directive  Security  Policy 
[CMA  Architecture  Team,  2007]. 

In  the  summer  of  2005,  USPACOM,  USNORTHCOM,  and  USEUCOM  initiated 
a  joint  collaborative  effort  to  develop  the  CMA  JCTD  capability.  This  JCTD  was 
planned  to  accomplish  MDA  in  three  spirals.  Spiral  I  focuses  on  the  establishment  of 
baseline  information  exchange  in  the  coalition  environment  with  stakeholder 
participation  from  the  Republic  of  Singapore,  USPACOM  Pacific  Fleet  Command 
(COMPACFLT),  and  maritime  analysts.  Spiral  II  focuses  on  the  internal  U.S. 
interagency  maritime  information  exchange  and  Spiral  III  focuses  on  implementing  net- 
centric  information  management  capability  and  demonstrating  products  relating  to  the 
MDA  COI  [CMA  Architecture  Team,  2007]. 

a.  Operational  Environment 

Requirements  have  been  established  to  integrate  information  from  the 
DOD,  U.S.  Coast  Guard,  Coalition/Allied  forces  and  commercial  maritime  entities.  From 
these  sources  disparate,  tracking  and  other  types  of  informational  data  must  be  integrated 
into  a  UDAP,  which  can  be  tailored  for  situation  awareness. 

There  were  three  operational  concerns  identified  in  maritime  tracking. 
The  concerns  were  as  follows: 

•  An  MLS  solution  must  be  identified  for  data  sharing 
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•  The  warfighter’s  systems  do  not  have  the  capability  required  to 
integrate  data  from  disparate  sources 

•  There  is  no  single  organization  that  can  effectively  coordinate 
Continent  United  States  (CONUS)  and  Global  requirements 
necessary  for  MDA 

The  concerns  regarding  the  integration  of  MDA  are  part  of  a  larger 
problem  the  warfighters  have  with  Command,  Control,  Communications,  Computers, 
Intelligence,  Surveillance,  and  Reconnaissance  (C4ISR).  A  requirement  was  identified  to 
provide  an  MDA  capability  to  automatically  detect,  track  and  identify  any  movement  of 
vessels  in  the  assigned  area  of  responsibility.  This  information  was  identified  as  a  support 
for  Command  and  Control  (C2)  decision-making. 

The  gathered  MDA  infonnation  must  be  consolidated,  disseminated  and 
displayed  in  a  tailored  presentation.  “The  intent  of  CMA  is  to  highlight  threat 
information  to  maritime  analysts  as  soon  as  possible,  thereby  increasing  reaction  time  and 
providing  greater  opportunity  to  monitor  and/or  interdict  these  threats  at  greater 
distances”  [United  States  Navy,  2007]. 

6.  CMA  JCTD-Interim  Report  on  Architecture  Version  0.2 

The  CMA  JCTD  Interim  Report  on  Architecture  was  a  key  document 
summarizing  the  work  done  to  date  by  the  CMA  Architecture  team.  This  document  not 
only  outlined  the  work  products  that  were  currently  available  but  also  included  a  section 
that  provided  an  assessment  of  the  current  architecture  and  the  way  ahead.  The  following 
is  a  synopsis  of  the  processes,  tools,  architecture  and  implementation  guidance  detailed  in 
this  document. 


a.  CMA  Business  Processes 

As  a  result  of  the  second  workshop  seven  CMA  business  processes  have 
been  defined.  These  processes  were  also  modeled  with  the  Universal  Modeling 
Language  (UML)  2.0.  The  business  processes  consist  of  the  following: 

•  A  User  Defined  Subscription 
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•  First  Hand  Reporting 

•  Threat  Identification  and  Prioritization 

•  Data/Information  Sharing 

•  New  Information  Source  or  Capability  Incorporation 

•  Security  Auditing 

•  Continuous  Improvement 

b.  Network  Architecture 

As  discussed  in  the  CMA  JCTD  CONOPS,  CMA  uses  the  Combined 
Enterprise  Regional  Information  Exchange  System  (CENTRIXS)  network  structure  to 
share  information  with  international  partners.  The  software  was  based  on  a  SOA  and 
utilized  both  collaboration  and  integration  tool  sets.  CMA  utilized  existing  networks  with 
tailorable  information  flows  to  exchange  information  at  the  appropriate  security  levels. 

c.  CMA  Core  Collaborative  Tool  Sets 

The  CMA  core  collaborative  tool  sets  included  email,  chat  and  web 
services.  The  DOD  and  Services  Defense  Planning  Guidance  identified  these  tool  sets  as 
“required  technology”.  Other  capabilities  such  as  voice  over  Internet  Protocol  (IP)  and 
video  teleconference  may  be  used  in  the  future  but  are  currently  unavailable  due  to  the 
bandwidth  limitation  of  CENTRIXS.  The  CMA  Enterprise  Service  also  provided  other 
services,  which  included  mapping,  notification,  information  assurance  management,  and 
authentication  and  authorization  services. 

B.  DERIVED  REQUIREMENTS 

At  the  conclusion  of  the  literature  review,  a  list  of  requirements  relevant  to  the 
extension  of  CMA  was  identified.  Table  1  provides  a  consolidated  listing  of  these 
requirements.  Each  requirement  is  listed  beneath  the  document  that  it  was  derived  from 
and  given  a  reference  number  that  is  used  in  the  traceability  matrix  discussed  in  the 
System  Requirements  discussion  below. 
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Table  1.  Derived  Requirements 


Document 

Reference 

Number 

Derived  Requirement 

National  CONOPS  to  Achieve  Maritime  Domain  Awareness.  The  system  shall: 

1. 

Provide  a  secure,  collaborative,  information- sharing  environment  and 

unprecedented  access  to  decision-quality  information.  A  fundamental 

attribute  of  a  net-centric  environment  is  the  ability  for  any  consumer  of 

information  to  get  the  information  that  is  needed,  when  it  is  needed 

2. 

Provide  pertinent  data,  products,  alerts,  and  warnings  to  support  decision 

makers,  analysts,  and  responders  within  the  GMCOI 

3. 

Provide  the  necessary  level  of  awareness  to  the  end-users  for  information 

about  specific  MDA  pillars 

4. 

Provide  a  multi-level  security  and  access  structure  as  appropriate,  tailored 

to  enable  users  to  pull  appropriate  information  and  data  from  the  network, 

and  to  receive  alerts  and  warnings  pushed  from  the  network  to  users 

5. 

Grant  user  access  and  provide  data  and  services  control  based  on  roles, 

responsibilities  and  authorities  within  the  multi-level  security  enterprise 

6. 

Provide  a  user  defined  awareness  picture  (UDAP).  The  UDAP  will 

provide  a  shared  display  of  friendly,  enemy/suspect,  and  neutral  tracks  on 

a  map  with  applicable  geographically  referenced  overlays  and  data 

enhancements.  The  UDAP  environment  may  include  distributed  data 

processing,  data  exchange,  collaboration  tools,  and  communications 

capabilities.  The  UDAP  may  include  information  relevant  to  the  tactical 

and  strategic  level  of  command.  This  includes,  but  is  not  limited  to, 

geographic  information  systems  data,  assets,  activities  and  elements, 

planning  data,  readiness  data,  intelligence,  reconnaissance  and 

surveillance  data,  imagery,  and  environmental  data 
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Document 

Reference 

Number 

Derived  Requirement 

Fleet  CONOPS  for  Maritime  Domain  Awareness.  The  system  shall: 

7. 

Provide  flexible,  scalable,  and  tailorable  techniques,  processes,  and 

procedures  that  can  be  adapted  rapidly  and  securely 

8. 

Provide  reliable  communications  between,  and  among,  nodes  in  the  MDA 

network 

9. 

Implement  a  service  oriented  architecture  (SOA)  that  will  provide  multi¬ 
level  security,  information  assurance,  storage,  and  performance 

management  for  a  robust  recovery  capability.  The  architecture  will  allow 

appropriate  information  exchange  transparency  between  non-classificd, 

classified  and  unclassified  domains,  as  well  as  across  numerous 

contributing  agencies.  An  SOA  will  enable  the  MOC  and  fleet  units  to 

publish  and  subscribe  to  common-source  data  in  order  to  develop  a 

common  understanding  through  a  UDAP.  It  is  a  picture  of  the  current 

state  of  the  maritime  environment  with  available  layers  of  information 

that  includes  information  specific  to  the  vessel  such  as  history, 

destination,  crew,  cargo,  affiliation,  etc 

10. 

Provide  effective  and  efficient  training  across  the  spectrum  of  activities 

from  individual  skills  development,  to  unit  and  composite  group  training 

CMA  Implementing  Directive  (JROC  Approved).  The  system  shall: 

11. 

Provide  an  SOA  based  operational  capability  to  perfonn  MDA  functions 

CMA  CONOPS  The  system  shall: 

12. 

Provide  the  capability  to  rapidly  assemble  a  theater  wide  maritime  picture 

and  disseminate  selected  track  information  to  international  and 

interagency  partners  through  classified  and  unclassified  networks  using 

appropriate  security  guards 
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Document 

Reference 

Number 

Derived  Requirement 

13. 

Use,  develop  or  modify  the  automated  decision  aid  to  display  information 

in  a  UDAP  environment  and  leverage  service  oriented  architecture  to 

manage  data,  enable  data  exchanges  and  provide  CMA  participants  with 

the  means  to  display  data  sets  meeting  their  respective  requirements 

14. 

Include  e-mail,  chat  and  web  services  as  its  core  tools.  Voice  over  IP 

(VoIP)  and  video  teleconference  capabilities  are  envisioned  to  be  part  of 

the  CMA  capability 

15. 

Develop  a  service  oriented  architecture  that  will  fuse  this  information  and 

integrate  it  with  automated  vessel  tracking  capabilities  to  develop  a 

comprehensive  maritime  picture 

16. 

Provide  an  open-system  architecture  that  facilitates  accurate,  timely  and 

inter-operable  information  and  intelligence  sharing  and  promotes 

collaboration  among  the  GMCOI 

17. 

Consolidate  unclassified  data  for  CMA  through  the  use  of  local, 

commercial,  and  other  readily  available  source  information.  Data,  as 

appropriate,  will  be  consolidated  and  passed  to  higher  classified  systems. 

Either  of  these  can  make  the  originally  unclassified  data  classified.  As 

such,  this  newly  formatted  data  is  passed  through  a  Multi-Level  Security 

Guard  onto  the  appropriate  servers  and  databases 

18. 

Provide  depot  level  maintenance 
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Document 

Reference 

Number 

Derived  Requirement 

19. 

Provide  security  requirements  will  comply  with  those  standards  delineated 

in  appropriate  DoD  Operational  Security  (OPSEC)  Instructions.  Security 

measures  will  support  the  five  fundamental  information  assurance 

elements  (confidentiality,  integrity,  availability,  authentication,  and  non¬ 
repudiation)  and  will  define  how  CMA  manages,  protects,  and  distributes 

sensitive  information.  System  accreditation  will  be  the  responsibility  of 

the  Designated  Approval  Authority  (DAA) 

20. 

Provide  warfighters  the  capability  to  accurately  display  all  available 

military  and  commercial  maritime  data  on  the  UDAP 

21. 

Enhance  the  value  of  existing  systems  by  allowing  their  Position  Location 

Information  (PLI)  data  to  be  displayed  on  the  UDAP  and  providing  a 

mechanism  for  multi-source  correlation,  providing  increased  situation 

awareness 

Source:  Documents  identified  by  stakeholders  as  key  to  this  thesis  were  reviewed  and  the 
derived  requirements  were  compiled. 


C.  STAKEHOLDER  ANALYSIS 

Stakeholder  Analysis  was  performed  to  determine  and  validate  the  people  relevant 
to  the  problem,  and  to  capture  their  requirements  for  the  system.  The  stakeholders,  or 
customers,  have  significant  interest  and/or  investment  in  the  problem  and  its  solution. 
The  primary  customers  for  the  xCMA  effort  were  identified  as  the  MDA  Project  Deputy 
and  Transition  Manager,  PEO-C4I  and  his  team.  Mr.  John  M.  Green  and  Dr.  Rachel 
Goshorn,  the  advisors  and  coordinators  for  this  effort,  and  were  also  identified  as 
stakeholders.  CMA  was  based  on  the  MDA  concepts  and  policies.  Due  to  the  primary 
focus  for  this  effort  being  on  CMA,  the  stakeholders  were  limited  to  those  listed  above  to 
ensure  that  guidance  received  is  directly  applicable  to  the  problem  at  hand. 
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Due  to  the  parallel  development  efforts  of  the  CMA  JCTD,  stakeholder  inputs  and 
communications  were  under  the  direction  of  Dr.  Rachel  Goshorn  and  consisted  of  limited 
interviews  and  email  exchanges.  The  requirements  received  from  the  stakeholders  were 
compiled  and  have  been  included  in  Table  2. 


Table  2. 

Stakeholder  Requirements 

Document 

Reference 

Number 

Stakeholder  Requirement 

Statement  of  Work.  The  system  shall: 

22. 

Extend  Comprehensive  Maritime  Awareness  (CMA)  to  disconnected  nodes 

to  facilitate  continued  information  sharing 

23. 

Operate  within  the  size,  power  and  weight  constraints  similar  to  small 

vessels  and  assumes  max  distance  to  node  4  of  30  mn 

Stakeholder  Analysis.  The  system  shall: 

24. 

Handle  a  minimum  Bandwidth  of  128  Kbps 

Source:  Statement  of  Work  and  stakeholder  feedback  via  interviews  and  email  exchange 
established  this  list  of  stakeholder  requirements. 


D.  SYSTEM  REQUIREMENTS 

The  culmination  of  the  Needs  Analysis  and  Requirements  Definition  activities  are 
the  system  requirements  for  the  xCMA  system.  These  are  comprised  of  the  derived 
requirements  identified  in  the  literature  review  activities  and  the  stakeholder  requirements 
provided  by  the  stakeholder.  These  requirements  are  listed  in  Table  3. 
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Table  3.  System  Requirements 


xCMA  System  Requirements 

Defining  Documents 

1 

D 

O  03 

3  © 

1  | 
d  i 

il 

>  g 

2  :s 

3  B 

Fleet  CONOPS  for  Maritime 

Domain  Awareness  (7-10) 

CMA  Implementing  Directive 
(JROC  Approved)  (11) 

CMA  CONOPS  (12-21) 

SOW  (22-23) 

Stakeholder  Communications 

(24) 

Provide  secure  connection  of  Node  5  to  CMA  Node  4 

1,4,5 

8 

19 

Provide  unclassified  warnings  and  alerts 

2,4 

Provide  unclassified  UDAP 

6 

9 

13,20 

Provide  access  to  all  required  info 

1,4,5 

24 

Provide  access  to  web  services 

14 

24 

Provide  capability  to  store  data  and  info 

13 

Provide  intuitive  human  system  interface 

6 

9 

13,20 

Provide  scalable  system  -  maximize  interoperability 

6 

7 

13,24 

Provide  flexible  system  -  allow  user  display  customization 

6 

7 

13 

Provide  accurate  data  and  info 

2,3 

16,  20,  24 

Provide  accurate  local  data  and  info 

2 

13,16,17,20 

24 

Provide  a  portable  system 

23 

Provide  reliable  system 

8 

18 

22 

Provide  flexible  system  operator  training 

10 

Minimum  Bandwidth  =128  Kbps 

24 

Connect  with  CMA 

1,4,5 

8 

19 

22 

Receive  data  and  information 

1,2,3, 4 

8,  9 

11 

12,16,17,21 

22 

24 

Transmit  data  and  information 

8,9 

11 

12,13,14,16 

22 

24 

Manage  data  and  information 

9 

13,19 

Provide  unclassified  collaboration 

1,4,6 

8,9 

14,16 

Provide  open  architecture  design 

7 

16 

Provide  plug  and  play  interface 

7 

16 

Provide  Graphical  User  Interface  (GUI) 

6 

9 

13,20,21 

Provide  Computer  Based  Training  (CBT) 

10 

Provide  depot  only  maintenance  paradigm 

18 

Provide  Ao  =  0.9 

8 

18 

22 

Provide  MTBF  =  1500  hrs 

8 

18 

22 

Operating  radius  =  30  nautical  miles 

23 

Source:  These  xCMA  requirements  were  pulled  from  key  documents  identified  by  the 
stakeholders.  The  left  column  is  a  list  of  all  the  requirements.  The  columns  to  the  right 
each  identifies  a  specific  document.  The  numbers  in  each  of  these  columns  corresponds 
to  a  requirement. 
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III.  VALUE  SYSTEM  DESIGN 


The  next  phase  in  the  tailored  systems  engineering  process  is  value  system  design. 
This  phase  consisted  of  an  Input/Output  Analysis,  Functional  Analysis,  Functional 
Hierarchy  and  Quality  Functional  Deployment  (QFD)  analysis.  See  Figure  6  for  a 
detailed  illustration.  The  purpose  of  this  phase  in  the  systems  engineering  process  was  to 
identify  a  set  of  objectives  and  evaluation  measures.  In  addition,  multi-dimensional 
attributes  and  decision  criteria  were  developed  to  provide  guidance  during  the  remainder 
of  the  system  engineering  process  and  to  ensure  selection  of  the  most  appropriate  system. 

This  phase  begins  with  the  identification  of  the  input,  output  and  functional 
requirements  and  functional  interaction  between  Node  4  and  Node  5.  It  then  proceeds 
with  the  identification  of  objectives  and  evaluation  measures  in  the  form  of  a  functional 
hierarchy.  At  this  point  an  effective  need  statement  was  defined  based  on  the  needs 
analysis.  Finally,  QFD  analysis  was  applied  to  promote  integration  of  organizational 
functions  and  to  facilitate  responsiveness  to  the  system  and  stakeholder  requirements. 
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Figure  6.  Value  System  Design  Phase. 

This  drawing  shows  the  relationship  of  the  Value  System  Design  Phase  to  the  other 
activities  in  the  system  engineering  process.  The  green  square  in  the  figure  indicates  the 
current  position  in  the  tailored  engineering  process. 


A.  INPUT-OUTPUT  ANALYSIS 

In  addition  to  understanding  the  problem  and  the  customer’s  needs,  it  was 
necessary  to  adequately  determine  the  boundary  conditions  and  scope  of  the  problem.  To 
facilitate  this,  the  xCMA  system  was  evaluated  from  a  component  and  structural 
perspective.  This  resulted  in  the  identification  of  two  nodes  of  interest,  the  gateway  node 
(Node  4)  and  the  disconnected  node  (Node  5),  as  well  as  the  overarching  CMA 
Architecture.  These  are  key  elements  in  defining  the  core  of  the  xCMA  system  and 
provided  the  boundaries  and  constraints  under  which  it  must  function. 

The  scope  of  this  effort  is  limited  to  a  point-to-point  connection  between  Node  4 
and  a  disconnected  Node  5.  A  system  context  diagram  was  generated  detailing  the  inputs 
and  outputs  of  the  overall  system  and  is  shown  in  Figure  7. 
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User  Requests 


Communications  Users 


Figure  7.  xCMA  Context  Diagram 

This  is  the  Context  Diagram,  from  the  Node  5  perspective,  of  the  xCMA  system.  It 
depicts  the  information  flow  between  the  system  and  the  Node  4  Gateway. 


Definitions  of  the  inputs/outputs  of  the  xCMA  system  are  shown  in  Figure  8,  the 
Operational  Node  Connectivity.  Each  of  the  identified  inputs  and  outputs  are  detailed 
below  for  clarification. 
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Subscription  Information 


(1) 


Web  Services  Information 

(2) 

COI  Information 

(3) 

Warnings  and  Alerts 

(4) 

Local  Awareness 

(5) 

Authentication  Request 

(6) 

Geolocation  Information 

(7) 

UDAP 

(8) 

Bandwidth  Allocation 

(9) 

Vessel  Information 

(10) 

CMA  Information 

(11) 

Scalable  Bandwidth 

(12) 

Validated  Authentication 

(13) 

Own  Ship  Position 

(14) 

NODE  5 


Figure  8.  Operational  Node  Connectivity  (OV-2). 

This  diagram  details  the  input  and  output  information  and  the  directional  flow  from  Node 
4  and  Node  5. 


1.  Subscription  Information:  Subscription  Infonnation  defined  as  an  input  and  output  to 
the  proposed  system.  The  local  Node  5  user  enters  relevant  subscription  information 
(input)  based  on  the  required  data.  The  system  sends  the  subscription  information  to 
Node  4  for  processing  (output). 

2.  Web  Services  Information:  Web  Services  Information  provides  access  to  a  web 
browser,  chat  functions,  e-mail  and  collaboration  tools  for  the  disconnected  Node  5.  Web 
Services  Information  defined  as  both  an  input  and  output  to  the  proposed  system  since  the 
flow  of  information  is  bi-directional  to  and  from  Node  5. 

3.  COI  Information:  COI  Information  was  defined  as  an  input  to  the  proposed  system 
and  was  provided  in  the  form  of  a  web  based  data  repository  by  Node  4.  The  proposed 
system  has  the  capability  to  store  and  access  this  database  locally  with  updates  being 
provided  through  the  Node  4  gateway. 
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4.  Warnings  &  Alerts:  Warnings  and  Alerts  were  defined  as  an  input  and  output  of  the 
proposed  system.  The  proposed  system  shall  be  capable  of  receiving  Warnings  and 
Alerts  via  Node  4  (input)  to  be  provided  to  Node  5.  Node  5  sends  locally  generated 
Warnings  and  Alerts  (output)  to  Node  4  via  the  proposed  system. 

5.  Local  Awareness:  Local  Awareness  was  defined  as  an  input  and  output  to  the 
proposed  system  and  defined  as  being  provided  by  Node  5.  Node  5  inputs  any  Local 
Awareness  it  has  from  onboard  sensors  which  will  be  provided  to  Node  4  (output). 

6.  Authentication  Request:  The  Authentication  Request  was  defined  as  an  input  to  the 
proposed  system  and  was  tied  to  the  system’s  physical  location  and  Network  Address. 
Some  additional  form  of  authentication  was  detennined  necessary  to  ensure  the  person 
accessing  the  CMA  network  was  authorized  to  obtain  CMA  information.  Additional 
authentication  requirements  were  detailed  in  the  Authentication  Policy  provided  by  the 
CMA  architecture. 

7.  Geolocation  Information:  Geolocation  was  defined  as  the  real-world  geographic 
location  of  the  connected  system  and  an  input  to  the  proposed  system.  Geolocation 
Infonnation  provided  automatically  by  the  systems  position  location  information 
capability. 

8.  UDAP:  The  UDAP  was  defined  as  an  output  of  the  proposed  system.  The  UDAP 
was  also  defined  as  an  output  to  a  display  on  the  xCMA  system.  The  UDAP,  sent  by 
Node  4,  is  dependent  on  the  own  ship  position  information,  vessel  information  and  user 
requirement. 

9.  Bandwidth  Allocation:  Bandwidth  Allocation  was  defined  as  an  input  to  the 
proposed  system  and  provided  by  Node  4.  Allocation  of  bandwidth  depends  on  the  user 
requirements  for  information  and  urgency/priority  of  the  needed  information. 
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10.  Vessel  Information:  Vessel  information  was  an  output  of  the  proposed  system.  A 
Node  5  user  inputs  required  data  on  his  own  vessel  and  send  this  infonnation  to  Node  4. 

1 1 .  CMA  Infonnation:  CMA  Information  was  defined  as  an  Input  to  the  proposed 
system.  CMA  Infonnation  provided  by  Node  4  to  the  system  consists  of  information 
fused  and  analyzed  by  the  CMA  architecture  or  Node  4. 

12.  Scalable  Bandwidth:  Scalable  Bandwidth  was  defined  as  an  output  of  the  proposed 
system  and  depends  on  the  user  requirements  and  priorities  for  receiving  updated 
information. 

13.  Validated  Authentication:  Validated  authentication  was  defined  as  an  output  of  the 
proposed  system.  The  Node  5  user  requests  authentication  as  an  input.  The  output  of  this 
request  is  the  validated  authentication.  Without  a  valid  authentication  Node  5  is  unable 
to  connect  to  the  CMA  architecture. 

14.  Own  Ship  Position:  Own  ship  position  was  defined  as  an  output  of  the  proposed 
system  and  gives  the  geolocation  information  for  the  vessel. 

The  value  of  the  input-output  analysis  is  in  the  big  picture  view  of  the  system 
inputs  and  outputs  and  boundaries.  It  provides  a  succinct,  singular  view  of  the  system 
interdependencies  and  provides  insight  into  the  development  of  the  Functional  Analysis. 

1.  Functional  Analysis 

A  functional  analysis  was  performed  to  understand  the  proposed  system  from  a 
functional  viewpoint.  The  functional  description  allows  for  the  system  to  be  designed 
independent  of  any  specific  technical  solution.  This  facilitates  the  evaluation  of  all 
technical  options  prior  to  implementing  a  specific  technical  approach.  A  functional 
decomposition  provides  reasons  for  the  different  physical  components  or  equipment 
selected  to  implement  the  system.  Thinking  of  the  system  in  functional  terms  provides  a 
basis  for  developing  innovative  alternatives. 
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For  the  xCMA  system,  the  high  level  functionality  consists  of  three  functions, 
Connect  with  CMA,  Provide  Collaboration,  and  Manage  Information .  The  definitions  of 
these  functions  are  shown  below. 

•  1.0  Connect  with  CMA  -  functionality  involved  with  physically  connecting 
the  disconnected  vessel  with  the  Node  4  Functional  Gateway,  including 
locating  and  identifying  the  system. 

•  2.0  Provide  Collaboration  -  bidirectional  communication  between  the 
disconnected  node,  Node  5,  and  the  Node  4  gateway.  This  includes  sending, 
receiving  and  displaying  all  information  including  web  services,  UDAP,  COI 
Database,  etc. 

•  3.0  Manage  Information  -  managing  and  handling  of  information  local  to  the 
disconnected  node.  This  includes  data  storage,  and  send,  search  and  retrieval 
functionality. 

These  functions  are  then  further  analyzed  to  detail  the  lower  level  subfunctions  as 
part  of  the  functional  decomposition.  This  functional  decomposition  is  detailed  in  Figure 
9  and  a  description  of  each  function  is  listed  in  Table  4. 
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Figure  9.  xCMA  Functional  Decomposition. 

This  figure  details  the  decomposed  functions  and  sub-functions  of  the  xCMA  system  as  derived  from  the  system  requirements  defined 
in  the  Problem  Definition  Phase. 


Assumptions: 

1.  Node  5  stores  48  hours  of  data  locally 


44 


Table  4.  xCMA  Function  and  Sub-function  Descriptions 


Reference 

Function 

Definition 

1.0 

Connect  with  CMA 

This  category  of  functions  includes  the  functionality  involved  with 
physically  connecting  the  disconnected  vessel  with  the  Node  4  Functional 
Gateway,  including  locating  and  identifying  the  system  and  vessel. 

1.1 

Archieve  Network  Connectivity 

This  function  represents  the  direct  network  connection,  (RF,  Satellite 
etc)from  Node  4  and  the  xCMA  system  including  the  hardware 
connectivity,  the  handshaking  and  network  negotiations. 

1.2 

Identify 

This  function  represents  the  unique  hardware  identification  of  the  xCMA 
system  itself.  For  example,  this  may  include  the  unique  Media  Access 
Control  (MAC)  address  or  on-chip  hardware  identification. 

1.3 

Locate 

This  function  represents  the  ability  of  the  xCMA  system  to  obtain  it's 
location  via  a  global  positioning  system  or  equivalent. 

2.0 

Provide  Collaboration 

This  category  of  functions  includes  bi-directional  communication  between 
the  disconnected  node,  Node  5,  and  the  Node  4  gateway.  This  includes 
sending,  receiving  and  displaying  all  information  including  web  services, 
UDAP,  COI  DB  etc. 

2.1 

Receive  Information 

This  function  represents  the  ability  of  the  system  to  receive  all  incoming 
CMA  information  or  system  operational  inputs.  Each  of  the  following 
functions  identify  the  category  of  information  or  data  being  received.  This 
information  includes:: 

2.1.1 

Receive  CMA  Info 

CMA  Information 

2.1.2 

Receive  Position  Info 

Position  Information 

2.1.3 

Receive  Alerts  &  Warnings 

Alerts  &  Warnings  Information 

2.1.4 

Receive  Archived  Info 

Archived  Information 

2.1.5 

Receive  COI  DB  Info 

COI  DB  Information 

2.1.6 

Receive  Web  Services  Info 

Web  Services  Information 

2.2 

Send  Information 

This  function  represents  the  ability  of  the  system  to  send  relevent  and 
required  information  or  data.  This  information  includes:: 

2.2.1 

Send  Ownship  Info 

Vessel  Information  and  Ownship  Position 

2.2.2 

Send  Subscription  Info 

Subscription  Information 

2.2.3 

Send  Local  Awareness 

Local  Awareness  -  on-board  sensor  information 

2.2.4 

Send  Alerts  &  Warnings 

Local  Alerts  &  Warnings  Information 

2.2.5 

Send  Web  Services  Info 

Node  5  Web  Services  Information 

2.3 

Display  Info 

This  function  represents  the  ability  of  the  system  to  display  all  CMA 
relevent  information.  This  information  includes:: 

2.3.1 

Display  Archived  Info 

Previously  stored  information 

2.3.2 

Display  UDAP 

Vessel  requested  awareness  picture 

2.3.3 

Display  Web  Services  Info 

Node  5  Web  Services  Information 

2.3.4 

Display  Alerts  &  Warnings 

CMA  Alerts  &  Warnings  Information  for  AOI 

2.3.5 

Display  COI  DB  Info 

Requested  COI  DB  Information 

3.0 

Manage  Information 

This  function  represents  the  ability  of  the  system  to  retain  and  provide 
access  to  24-48  hours  worth  of  information. 

3.1 

Store  Information 

This  function  represents  the  ability  of  the  system  to  store  the  received 
information. 

3.2 

Purge  Information 

This  function  represents  the  ability  of  the  system  to  delete  previously 
stored  information,  either  based  on  a  time  dependent  action  or  user 
request. 

3.3 

Access  Information 

This  function  represents  the  ability  of  the  system  to  access  previously 
stored  information. 

3.3.1 

Sort  &  Search  Info 

This  function  represents  the  sort  and  search  capability  of  the  system  that 
supports  the  ability  to  display  archived  information  as  requested  by  the 

user. 

3.3.2 

Retrieve  Info 

This  function  represents  the  ability  of  the  system  to  retrieve  the  previously 
stored  information. 
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The  hierarchy  of  functions  is  generated  from  the  functional  decomposition.  It  starts  with 
the  effective  need  statement  and  supports  decomposition  of  existing  functions  into  subfunctions 
to  provide  a  more  accurate  view  of  current  functionality.  This  facilitates  the  identification  of  the 
objectives  and  evaluation  measures  for  all  lower  level  functions.  These  objectives  and  their 
corresponding  evaluation  measures  are  shown  in  Table  5.  The  sources  of  the  values  used  in  the 
evaluation  measures  were  a  combination  of  guidance  from  standards  documents  (i.e.  Mean  Time 
Between  Failure  (MTBF)  =  1500  hours  (hrs),  MIL-PRF-28800F),  similar  functional  systems, 
and  expert  knowledge.  All  system  availability  numbers  assume  that  the  network  and  all 
components  of  the  system  are  fully  functional.  Therefore,  the  system  availability  of  100%  for 
Receipt  of  Alerts  &  Warnings  represents  the  expectation  that  all  of  these  high  priority  alerts  will 
be  received  when  the  xCMA  system,  Node  4  and  the  connecting  network  are  fully  functional. 
Data  correctness  refers  to  the  format  of  the  information  received,  sent  and/or  displayed.  The 
Functional  Hierarchy  for  the  xCMA  system  is  depicted  in  Figure  10. 

Finally  functional  flow  block  diagrams  were  developed  to  show  the  functional 
interactions  and  provide  a  better  understanding  of  the  system.  These  tools  were  utilized  to 
collectively  come  to  better  understanding  of  the  process  required  to  extend  CMA  to  a 
disconnected  vessel.  The  flow  diagram  also  identified  those  functional  elements  conducted  in 
parallel,  and  those  requiring  feedback  loops.  During  the  analysis,  the  flow  was  reviewed  to 
ensure  that  the  process  accurately  represented  the  system  that  was  being  modeled.  The 
functional  flow  block  diagram  is  included  in  Appendix  C  and  was  useful  in  detailing  system 
interaction  and  determining  the  functional  relationships,  redundancies  and  dependencies. 
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Table  5.  xCMA  Function  and  Sub-function  Objectives  and  Evaluation  Measures 


Reference 

Function 

Objectives 

Evaluation  Measures 

1.0 

Connect  with  CMA 

1.1 

Archieve  Network  Connectivity 

Establish  and  maintain  connectivity 

Network  Up  Time  =  95% 

MTBF  =  1500  Hrs 

1.2 

Identify 

Maximize  Accuracy 

Identification  Accuracy=100% 

1.3 

Locate 

Maximize  Accuracy 

Location  Accuracy  within  +/- 10  m 

2.0 

Provide  Collaboration 

2.1 

Receive  Information 

2.1.1 

Receive  CMA  Info 

Increase  Data  Availability  &  Accuracy 

Data  Accuracy  =  90%;  A0=90% 

2.1.2 

Receive  Position  Info 

Maximize  Accuracy  &  Availability 

Accurate  within  +/-  10  m;  Available 
95% 

2.1.3 

Receive  Alerts  &  Warnings 

Increase  Data  Availability  &  Priority 

A0=100% 

2.1.4 

Receive  Archived  Info 

Maximize  Data  Availability 

A0=90% 

2.1.5 

Receive  COI  DB  Info 

Maximize  Data  Availability 

A0=90% 

2.1.6 

Receive  Web  Services  Info 

Increase  Data  Availability  &  Accuracy 

Data  Accuracy  =  90%;  A0=90% 

2.2 

Send  Information 

2.2.1 

Send  Ownship  Info 

Increase  Data  Correctness 

Probability  that  the  Data  is  Correct  95% 
of  the  time 

2.2.2 

Send  Subscription  Info 

Increase  Data  Correctness 

Probability  that  the  Data  is  Correct  95% 
of  the  time 

2.2.3 

Send  Local  Awareness 

Increase  Data  Correctness 

Probability  that  the  Data  is  Correct  95% 
of  the  time 

2.2.4 

Send  Alerts  &  Warnings 

Increase  Data  Correctness 

Probability  that  the  Data  is  Correct  95% 
of  the  time 

2.2.5 

Send  Web  Services  Info 

Increase  Data  Correctness 

Probability  that  the  Data  is  Correct  95% 
of  the  time 

2.3 

Display  Info 

2.3.1 

Display  Archived  Info 

Increase  Data  Correctness 

Probability  that  the  Data  is  Correct  95% 
of  the  time 

2.3.2 

Display  UDAP 

Increase  Data  Correctness 

Probability  that  the  Data  is  Correct  95% 
of  the  time 

2.3.3 

Display  Web  Services  Info 

Increase  Data  Correctness 

Probability  that  the  Data  is  Correct  95% 
of  the  time 

2.3.4 

Display  Alerts  &  Warnings 

Increase  Data  Correctness 

Probability  that  the  Data  is  Correct  95% 
of  the  time 

2.3.5 

Display  COI  DB  Info 

Increase  Data  Correctness 

Probability  that  the  Data  is  Correct  95% 
of  the  time 

3.0 

Manage  Information 

3.1 

Store  Information 

Maximize  Mission  Capacity 

Storage  of  nominal  Mission  Data=95% 

3.2 

Purge  Information 

Maximize  Mission  Capacity 

Storage  of  nominal  Mission  Data=95% 

3.3 

Access  Information 

3.3.1 

Sort  &  Search  Info 

Minimize  Data  Access  Time 

Data  Access  <  10  s 

3.3.2 

Retrieve  Info 

Increase  Data  Availability  &  Accuracy 

Data  Access  <  10  s 
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Figure  10.  Top  Level  Flierarchy  of  Functions  for  the  xCMA  system. 

This  diagram  shows  the  functions  and  sub-functions  as  defined  in  the  functional  decomposition  and  provided  the  identified  objectives 
and  evaluation  measures. 
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In  order  to  accurately  capture  the  behavior  and  infonnation  flow  through  the  xCMA 
system.  Integration  Definition  for  Function  Modeling  (IDEFO)  was  implemented.  IDEFO  is  a 
common  modeling  technique,  a  tool  to  aid  in  the  functional  analysis  and  was  used  to  create  a 
model  for  the  proposed  black  box  system.  The  IDEFO  model  was  used  to  show  data  flow, 
system  control,  and  the  functional  flow  of  the  proposed  system  to  extend  CMA  to  a  disconnected 
Node  5.  The  model  was  created  to  provide  a  precise  description  of  the  proposed  system  and 
promote  consistency  in  the  terms  being  used  and  their  interpretation.  The  IDEFO  products 
developed  in  support  of  this  effort  are  located  in  Appendix  D. 

The  IDEFO  model  consists  of  a  hierarchical  series  of  diagrams  and  text.  The  two  primary 
components  are  the  functions  and  data  that  inter-relates  to  those  functions.  The  IDEFO  model,  in 
conjunction  with  the  functional  analysis,  directly  supported  the  generation  of  the  Systems 
Communications  Description  System  View  (SV-2),  which  depicts  pertinent  information  about 
communications  systems,  links  and  networks  that  support  the  xCMA  systems.  The  SV-2  is  one 
of  several  DoDAF  products.  The  DoDAF  is  a  tool  that  provides  a  common  approach  for 
describing,  presenting,  and  integrating  architectures.  The  product  set  describes  a  method  of 
designing  a  system  in  terms  of  subcomponents,  often  referred  to  as  building  blocks,  and  detailing 
how  they  fit  together.  The  SV-2  for  the  xCMA  system  is  shown  in  Table  6. 

Decomposing  these  functions  further,  resulted  in  the  identification  of  subcomponents  of 
interest  which  include  interfaces  and  entities  that  make  up  the  system.  These  functions  are 
grouped  based  on  subcomponent  functionality.  This  functionality,  along  with  the  interfaces 
between  the  xCMA  system  and  system  nodes,  is  captured  in  the  Systems  Interface  Description 
(SV-1)  depicted  in  Figure  11.  This  diagram  shows  system  nodes  and  the  sub-systems  resident  at 
these  nodes  that  support  the  information  sharing  between  the  Node  4  gateway  and  the 
disconnected  Node  5  vessel.  To  augment  the  functional  flow,  and  detail  the  information  between 
the  Node  4  and  Node  5  systems,  the  Operational  Information  Exchange  Matrix  (OV-3)  was 
generated.  This  matrix,  shown  in  Table  7,  defines  the  triggering  events  and  the  priorities  of  the 
information  exchanges  required  of  the  xCMA  system. 
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Figure  11.  Systems  Interface  Description  (SV-1). 

This  diagram  details  the  system  interactions,  at  the  functional  component  level,  for  the  xCMA  system. 
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Table  6.  Systems  Communications  Description  (SV-2). 


Need  Line 

Info  Ex  ID 

Sending  Op 
Node 

Communication  Links  and 
Networks 

Receiving  Op 
Node 

Subscription  Information 

1 

Node  4 

Radio  Frequency  (RF) 
Wireless  Network/SOA 

Node  5 

Web  Services  Information 

2 

Node  4 

Node  5 

RF  Wireless  Network 

Node  5 

Node  4 

COI  Information 

3 

Node  4 

RF  Wireless  Network/SOA 

Node  5 

Warnings  &  Alerts 

4 

Node  4 

Node  5 

RF  Wireless  Network/SOA 

Node  5 

Node  4 

Local  Awareness 

5 

Node  5 

RF  Wireless  Network 

Node  4 

Authentication  Request 

6 

Node  4 

Node  5 

RF  Wireless  Network 

Node  5 

Node  4 

Geolocation  Information 

7 

Node  5 

RF  Wireless  Network 

Node  4 

UDAP 

8 

Node  4 

Node  5 

RF  Wireless  Network/SOA 

Node  5 

Node  4 

Bandwidth  Allocation 

9 

Node  4 

RF  Wireless  Network 

Node  5 

Vessel  Information 

10 

Node  5 

RF  Wireless  Network/SOA 

Node  4 

CMA  Infonnation 

11 

Node  4 

RF  Wireless  Network/SOA 

Node  5 

Scalable  Bandwidth 

12 

Node  4 

RF  Wireless  Network 

Node  5 

Validated  Authentication 

13 

Node  4 

RF  Wireless  Network 

Node  5 

Own  Ship  Position 

14 

Node  5 

RF  Wireless  Network/SOA 

Node  4 

The  SV-2  Systems  Communications  Description  table  details  need  lines  for  the  communication,  the  sending  and  receiving  nodes, 
communication  links  and  network  links. 
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Table  7.  Operational  Information  Exchange  Matrix  (OV-3). 


Need  Line 

Info  Ex 
ID 

Mission  Scenario 

Trigger  Event 

Timeliness 

Sending 
Op  Node 

Receiving  Op 
Node 

Subscription 

Information 

1 

Provide  Collaboration 

Per  Request 

Routine 

Node  4 

Node  5 

Web  Services 
Information 

2 

Provide  Collaboration 

User 

Routine 

Node  4 
Node  5 

Node  5 
Node  4 

COI  Information 

3 

Provide  Collaboration 

User 

Routine 

Node  4 

Node  5 

Warnings  &  Alerts 

4 

Provide  Collaboration 

Upon  Receipt 

Immediate 

Node  4 
Node  5 

Node  5 
Node  4 

Local  Awareness 

5 

Provide  Collaboration 

Upon  Updates 

Routine 

Node  5 

Node  4 

Authentication 

Request 

6 

Connect  with  CMA 

Upon  Connection 

Routine 

Node  4 
Node  5 

Node  5 
Node  4 

Geolocation 

Information 

7 

Connect  with  CMA 

Upon  Connection  and 
Periodic 

Routine 

Node  5 

Node  4 

UDAP 

8 

Provide  Collaboration 

Upon  Updates 

Routine 

Node  4 
Node  5 

Node  5 
Node  4 

Bandwidth 

Allocation 

9 

Connect  with  CMA 

Upon  Connection 

Routine 

Node  4 

Node  5 

Vessel  Infonnation 

10 

Provide  Collaboration 

User 

Routine 

Node  5 

Node  4 

CMA  Information 

11 

Provide  Collaboration 

Upon  Connection  and 
Updates 

Routine 

Node  4 

Node  5 

Scalable 

Bandwidth 

12 

Connect  with  CMA 

Upon  Connection 

Routine 

Node  4 

Node  5 

Validated 

Authentication 

13 

Provide  Collaboration 

Per  Request 

Immediate 

Node  4 

Node  5 

Own  Ship  Position 

14 

Provide  Collaboration 

User 

Routine 

Node  5 

Node  4 

The  OV-3  is  a  DODAF  product  that  provides  information  regarding  need  lines,  mission  scenario,  trigger  events,  timeliness,  sending 
and  receiving  nodes. 
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The  output  of  the  Needs  Analysis,  which  consists  of  all  work  done  up  to  this 
point,  is  the  revised  problem  statement,  or  Effective  Need  statement.  It  is  created  through 
iteration,  feedback,  and  creativity  during  the  processes  utilizing  System  Decomposition, 
Stakeholder  Analysis,  and  Functional  Analysis.  This  Effective  Need  is  stated  below: 

“The  CMA  needs  a  robust,  flexible,  reliable,  user-friendly,  supportable  system  that 
receives,  provides  and  displays  relevant,  timely  situation  awareness  information  to 
non-integrated  vessels  to  facilitate  the  execution,  control,  and  assessment  of 
humanitarian  operations.  ’’ 

In  addition,  amplification  of  tenns  referenced  are  as  follows: 

-  Robust  -  graceful  degradation;  ability  to  connect  and  communicate  with 
the  CMA  via  Node  4 

-  Flexible  -  plug  and  play  capability,  mission  tailorable 

-  Reliable-operational  availability  of  0. 90  with  MTBF  of 1500  hours 

-  User-friendly  -automated  and  system-assisted  help  for  user 

-  Supportable  -Depot  level  maintenance  only 

-  Relevant  -  user  receives  requested  information 

-  Timely-in  sufficient  time  to  be  of  value  to  the  user 


B.  VALUE  SYSTEM  DESIGN 
1.  QFD 

The  QFD  model  was  used  to  enhance  the  xCMA  traceability  of  customer’s  high 
level  needs  to  system  functions  and  lower  level  attributes  of  potential  system  solutions. 
The  QFD  model  facilitates  the  systems  engineering  decision  making  process  through  the 
scoring  of  the  relationship  strength  between  each  requirement  and  attribute  of  the  model 
and  through  the  evaluation  of  the  interaction  for  positive  and  negative  impact  among  the 
model’s  attributes. 
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In  this  study,  three  QFD  models  were  used  to  focus  on  the  relationship  between 
customer  requirements  and  system  level  requirements,  system  level  requirements  and 
functional  requirements,  and  functional  requirements  and  evaluation  measures.  Figure  12 
depicts  these  models  graphically. 


Figure  12.  QFD  models  used  in  translating  customer  requirements  into  decision 
making  attributes. 

This  figure  also  shows  the  sources  of  information  and  flow  with  dependency  of  the  QFD 
models. 

In  this  QFD  analysis,  the  customer  requirements  and  system  level  requirements 
are  derived  from  the  National  CONOPS  to  Achieve  MDA,  Fleet  CONOPS  for  MDA, 
CMA  Implementation  Directive,  CMA  CONOPS,  SOW,  and  stakeholders.  See  Table  3 
in  Chapter  1  for  specific  reference  of  each  customer  requirement.  The  functional 
requirements  are  derived  from  the  functional  analysis.  The  evaluation  measures  are 
derived  from  the  value  hierarchy  analysis. 

In  order  to  support  the  decision  making  process,  the  three  QFD  models  were 
developed  to  methodically  translate  customer  desires  into  quantifiable  measures.  The 
first  translation  starts  with  the  customer  requirements  and  system  level  requirements.  This 
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analysis  scores  the  relationship  strength  for  the  customer  requirements  with  the  system 
level  requirements.  Furthermore,  the  analysis  evaluates  the  impact  of  interactions 
(positive,  negative,  neutral)  within  the  system  level  requirements.  The  second  translation 
uses  the  system  level  requirements  to  pair  with  the  functional  requirements.  This  analysis 
scores  the  relationship  for  the  system  level  requirement  and  functional  requirements. 
This  analysis  also  evaluates  the  attribute  interactions  within  the  functional  requirements. 
The  third  translation  uses  the  functional  requirements  to  bounce  off  the  evaluation 
measures.  This  particular  analysis  scores  the  functional  requirements  with  the  evaluation 
measures.  The  analysis  also  evaluates  the  interaction  within  the  evaluation  measures. 
The  QFD  results  are  discussed  in  the  sections  below. 

2.  QFD  with  Customer  Requirements  and  System  Level  Requirements 

The  interactions  of  the  system  requirements  in  the  Pareto  chart  in  Figure  13 
indicate  that  an  open  architecture  design,  a  plug  and  play  interface,  and  graphical  user 
interface  have  positive  interaction  with  the  core  functions  (connect,  receive,  transmit, 
display,  and  collaborate)  in  Node  5.  Furthermore,  maintaining  a  0.90  operational 
availability  and  MTBF  of  1500  hours  have  positive  interaction  with  the  core  functions  of 
Node  5  as  well. 

The  Pareto  results  also  illustrate  the  influence  of  the  customer  requirements.  The 
top  20%  of  the  attributes  of  the  xCMA  QFD  for  customer  requirements  and  system  level 
requirements  indicate  that  the  following  are  most  important: 

1 .  Displaying  data  and  infonnation  from  CMA  Node  4 

2.  Receive  data  and  information  from  CMA  Node  4 

3.  Providing  unclassified  collaboration 
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Influence  of  Customer  Requirements  on  System  Level  Requirements 


Systems  Level  Requirements 


Figure  13.  Influence  of  Customer  Requirements  on  System  Level  Requirements  for 
xCMA. 

This  Pareto  chart  helps  identify  the  most  important  System  Level  attributes  for  decision 
making  process. 


3.  QFD  with  System  Level  Requirements  and  Functional  Requirements 

The  interactions  of  the  system  functions  and  sub-functions  indicate  both  negative 
and  positive  interactions.  The  negative  interactions  are  seen  in  the  areas  pertaining  to 
system  bandwidth  and  throughput.  These  include  components  supporting  network 
operations,  display  and  system  storage.  The  Node  4  and  Node  5  connection  has  positive 
impact  on  the  core  functions  (connect,  receive,  transmit,  display,  and  collaborate)  in 
Node  5.  This  is  the  case  because  this  connection  is  required  by  the  xCMA  node.  The 
Pareto  diagram  in  Figure  14  provides  results  to  illustrate  the  influence  of  the  system  level 
requirements  on  functional  requirements.  The  top  20%  of  the  attributes  of  the  xCMA 
QFD  for  system  level  requirements  and  system  functions  and  sub-functions  indicate  that 
connecting  with  Node  4,  sending  subscription,  displaying  MDA  UDAP,  displaying  web 
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services,  displaying  warnings  and  alerts,  and  displaying  COI  information  have  the  highest 
influence  strength. 


Influence  of  System  Level  Requirements  on  System  Functions  and  Sub-Functions 


System  Functions  and  Sub-functions 


Figure  14.  Influence  of  System  Level  Requirements  on  Functional  Requirements  for 
xCMA. 

This  Pareto  chart  helps  identify  the  most  important  attributes  for  decision  making 
process. 

4.  QFD  with  Functional  Requirements  and  System  Evaluation  Measures 

The  interactions  of  the  evaluation  measures  indicate  negative  interactions  with 
regards  to  storage  bandwidth  limitations  and  data  sort,  search  and  retrieve  time.  Positive 
interactions  are  also  identified  in  geolocation  data  accuracy,  geolocation  data  availability, 
CMA  data  retrieved  accuracy,  CMA  data  availability,  incoming  warnings  and  alerts 
accuracy,  and  incoming  warnings  and  alerts  availability.  This  is  the  case  because  the 
CMA  data  and  warnings  and  alerts  are  pulled  from  Node  4,  which  are  based  on  the  own 
ship  location  data. 
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Figure  15  below  provides  Pareto  results  to  further  illustrate  the  influence  of  the 
functional  requirements  on  the  evaluation  measures.  The  top  20%  of  the  attributes  based 
on  relationship  strength  from  the  xCMA  QFD  for  functional  requirements  and  evaluation 
measures  indicate  that  network  up  time  and  network  connectivity  MTBF  are  the  most 
important  evaluation  measures  in  extending  CMA  to  Node  5. 


Influence  of  Functional  Requirements  on  System  Evaluation  Measures 


Evaluation  Measures 


Figure  15.  Influence  of  Functional  Requirements  on  Evaluation  Measures  for 
xCMA. 

This  chart  synopsizes  the  relationship  between  the  functional  requirements  and  stated 
evaluation  measures.  As  shown,  network  up  time  and  network  connectivity  (MTBF)  are 
the  two  most  influential  measurements. 


Following  analysis  of  the  Functional  Hierarchy  and  QFD,  the  positive  and 
negative  evaluation  measures  were  used  to  determine  MOE  for  the  xCMA  system.  These 
MOEs  are: 
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MOE  1:  Probability  that,  upon  command,  the  system  will  be  fully 
functional  within  4  hours  95%  of  the  time. 

MOE  2:  Probability  that  the  system  will  connect  to  the  CMA  within  10 
minutes  95%  of  the  time.  This  includes  network  connectivity,  system 
identification  and  geolocation. 

MOE  3:  Probability  that  the  system  will  operate  1500  hours  between 
failures  95%  of  the  time. 

MOE  4:  Probability  that  the  system  will  sustain  data  throughput  of  0.128 
Mbps  95%  of  the  time. 

In  summary,  the  value  system  design  phase  evaluated  the  system  requirements 
identified  in  the  Problem  Definition  Phase,  identified  the  functional  requirements, 
objectives  and  evaluation  measures  and  translated  these  requirements  into  engineering 
tenns  and  MOEs.  These  activities  directly  support  the  next  phase  of  the  process,  Design 
and  Analysis,  which  will  facilitate  the  generation  of  alternatives  and  support  decision 
making. 
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IV.  DESIGN  AND  ANALYSIS 


A.  DESIGN  &  ANALYSIS 

The  next  phase  in  the  tailored  systems  engineering  process  is  design  and  analysis. 
This  phase  consists  of  alternatives  generation,  including  development  of  alternatives, 
feasibility  screening,  and  modeling  and  simulation.  Figure  16  illustrates  the  relationship 
of  this  phase  to  the  overall  process. 


Figure  16.  Design  and  Analysis  Phase. 

This  phase  details  the  relationship  between  this  phase  and  the  remainder  of  the  system 
engineering  process.  The  focus  in  this  phase  is  on  alternatives  generation  and  modeling 
and  simulation.  These  activity  results  will  assist  in  the  decision  making  process. 


The  purpose  of  these  activities  is  to  identify  a  set  of  key  functions  and  evaluation 
measures  to  be  used  in  the  selection  of  the  best  candidate  system  configurations.  These 
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candidate  systems  are  then  modeled  and  simulated.  The  results  of  the  modeling  and 
simulation  provide  guidance  during  the  remainder  of  the  system  engineering  process  to 
ensure  selection  of  the  most  appropriate  system. 


B.  ALTERNATIVES  GENERATION 

The  Alternatives  Generation  phase  included  the  development  of  alternatives, 
feasibility  screening  and  recommended  alternatives.  The  results  from  the  Functional 
Analysis,  Functional  Hierarchy,  and  QFD  were  utilized  to  focus  the  efforts  in  generating 
alternatives  that  meet  the  requirements.  Alternatives  generation  identified  the  key  system 
functions  that  the  xCMA  system  requires  to  satisfy  the  effective  need.  These  key 
functions  were  used  in  the  development  of  the  various  xCMA  system  options.  These 
options  were  then  evaluated  with  the  MOEs  that  were  developed  using  the  evaluation 
measures  and  QFD.  This  process  is  called  feasibility  screening.  The  screened  system 
options  were  compiled  into  a  list  of  recommended  alternatives.  These  alternatives  were 
then  compiled  into  a  Raw  Data  Matrix  that  highlights  the  key  features  of  the  xCMA 
system.  The  key  features  and  representative  functionality  is  modeled  and  simulated  and 
the  results  used  to  assist  in  the  evaluation  and  decision  phase  and  in  the  selection  of  the 
most  appropriate  system. 

1.  Alternatives  Generation  Assumptions 

•  Due  to  the  sensitive  nature  of  military  equipment,  it  would  be 
restrictive  to  use  military  communications  equipment 

•  802.16m  is  a  viable  communication  means  by  implementation  date 

•  Web-based  protocols  are  implemented 

•  INMARSAT,  KU  band,  Ultra-High  Frequency  (UHF)  SATCOM, 
Transformational  Communications  Satellite  (TSAT)  are  combined 
into  SATCOM 

•  Commercial  SATCOM  will  use  commercial  router/modem  and 
military  SATCOM  will  use  Tactical  router/modem 
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•  802. 16  implementation  will  use  a  commercial  router/modem 

•  Host  to  Communications  (COMMS)  interface  is  condensed  into 
commercial  and  tactical  router/modem  that  will  be  internal  to  the 
xCMA  system 

•  Software  and  services  are  developed  and  controlled  by  the  CMA 
and  will  be  loaded  onto  the  host  system  prior  to  xCMA  system 
delivery  to  the  user 

•  Consideration  of  software  and  services  is  the  responsibility  of  the 
CMA  JCTD  and  will  not  be  evaluated  in  this  effort 

•  Display  systems  will  be  composed  of  conventional  displays  with 
an  option  for  new  technology 

•  User  interface  is  part  of  the  host  system 


2.  Alternatives  Generation  Critical  information  used  early  in  the 

decision  making  process 

•  Differential  GPS  (D-GPS)  was  excluded  due  to  its  limited 
operating  area  (requirement  calls  for  a  global  solution) 

•  Software  Defined  Radios  are  flexible  and  can  support  a  variety  of 
networks  (network  agnostic)  however  they  must  be  integrated  with 
either  SATCOM  or  Institute  of  Electrical  &  Electronics  Engineers 
(IEEE)  802.16 

•  Wireless  802.11  IEEE  range  is  less  than  10  miles,  therefore  does 
not  meet  the  30  mn  requirement 

•  INMARSAT  bandwidth  limitations  are  not  feasible  for  handling 
streaming  video 
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3.  Development  of  Alternatives 


The  development  of  alternatives  was  the  result  of  brainstorming  and  brainwriting 
activities  to  ensure  all  inputs  were  considered.  To  satisfy  the  effective  need,  the  three 
previously  defined  functions  from  the  Functional  Hierarchy  and  Value  Systems  Design, 
0 Connect  with  CMA,  Provide  Collaboration  and  Manage  Information)  were  used  during 
the  ensuing  evaluations.  A  reiteration  of  the  definitions  of  these  functions  is  shown 
below. 

•  1.0  Connect  with  CMA  -  functionality  involved  with  physically 
connecting  the  disconnected  vessel  with  the  Node  4  Functional  Gateway, 
including  locating  and  identifying  the  system. 

•  2.0  Provide  Collaboration  -  bidirectional  communication  between  the 
disconnected  node,  Node  5,  and  the  Node  4  gateway.  This  includes 
sending,  receiving  and  displaying  all  information  including  web  services, 
UDAP,  COI,  etc. 

•  3.0  Manage  Infonnation  -  managing  and  handling  of  information  local  to 
the  disconnected  node.  This  includes  data  storage,  and  send,  search  and 
retrieval  functionality. 

A  product  matrix  was  generated  identifying  system  categories  required  to  meet 
the  functionality  and  system  objectives  defined  in  the  functional  analysis  above.  The 
categories  and  identified  options  are  displayed  in  Table  9  and  were  the  result  of  several 
discussion  and  discovery  sessions.  From  this  product  matrix,  an  initial  set  of  72  xCMA 
system  options  were  generated.  A  table  of  these  options,  numerically  identified,  is 
included  in  Appendix  F. 
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Table  8.  Initial  xCMA  System  Categories  and  Options 


COMMS 

Host  System 

HOST  to 

COMMS  Interface 

PL1 

Display 

Identify 

User  Interfaces 

Storage 

Deployability 

INMARSAT  (L-Band) 

PDA 

Tactical  Internal 

Router 

DGPS  -  Internal 

Color 

NIC  (Network 
Interface  Card) 

keyboard 

Internal 

Man 

KU  Band  SATCOM 

Tactical  External 

Router 

touch  screen 

IMF  SATCOM 

Laptop 

Commercial 

Internal  Router 

Multiple 

Displays 

trackball 

HF-LOS 

Commercial 

External  Router 

DGPS  -  External 

IP  Based 

mouse 

External 

Ship 

UHF-LOS 

Desktop 

voice 

recognitions 

VHF-LOS 

Tactical  Internal 

Modem 

GPS  -  External 

Size 

mic  /  speakers 

Wireless 

(802.11/802.16) 

PC  Based 

Tactical  External 

Modem 

Other  Hardware 

headset 

Remote 

camera 

Helo 

TSAT 

Rack  mounted  SBCs 

Commercial 

Internal  Modem 

GPS  -  Internal 

Readable  in 
bright  light 

bio  recognition 

Removable 

New  Technology 

card  reader 

Software  Definable 

Radios 

Mobile  Terminal 
Equipment 

Commercial 

External  Modem 

Evaluation  Criteria 

Bandwidth 

Range  >=  30  Nmi 

Scalable 

Plug  &  Play 

Portable 

Expandable 

Supportable 

Maintainable 

Reliable 

Properly  interfaces 
between  Host  & 

COMMS 

Accuracy  =  +/- 
5meters 

(HSI) 

Accuracy  =  100% 

(HSI) 

24-48  hours  of 

information 

Probability 

=90-95% 

Access  <10s 

Sort  <10s 

Search  <  10s 

(HSI) 

In  an  attempt  to  reduce  the  options  to  a  viable  set  of  alternatives,  an  additional 
functional  evaluation  of  the  overall  system  was  applied.  A  conducted  priority  ranking 
was  applied  to  each  functional  category  based  on  the  risk  and  impact  that  each  has  on  the 
overall  system  and  its  objectives.  A  scale  of  1  to  10  was  applied  with  10  representing  the 
greatest  impact.  A  decision  was  made  by  the  engineering  team  to  group  together  the 
display  and  host  system  categories.  The  rationale  behind  this  decision  was  based  on  the 
understanding  that  the  host  system  type  is  indicative  of  the  associated  display  type.  For 
example,  a  laptop  solution  for  the  host  system  determines  a  Liquid  Crystal  Display 
(LCD)  for  the  display  type.  Figure  17  shows  the  final  functional  categories  and  the 
evolution  from  the  original  list  with  ranking/weighting  values  to  the  final  top  5. 
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|Functional  Category  Ranking 

f 

„ _ K 

Functional  Category 

Communications 

10.0 

Communications 

Identify 

9.5 

Identify 

Host  to  Comms  Interface 

9.0 

Host  to  Comms  Interface 

PLI 

9.0 

PLI 

Display 

8.0 

Host  System  (incl  Display)  A 

Host  System 

6.0 

Deployability 

5.0 

User  Interface 

4.0 

User  Interface 

Storage 

4.0 

Storage 

Figure  17.  Functional  Categories. 

During  alternatives  generation,  it  was  necessary  to  reduce  the  options  to  a  realistic 
number.  To  accomplish  these  rankings  were  applied  to  the  functional  categories  to 
determine  which  functional  areas  needed  to  be  the  focus.  This  diagram  shows  the 
evolution  of  these  categories  and  their  relative  ranking  factors. 

It  was  determined  that  although  Manage  Information  is  an  important  part  of  the 
system,  the  functionality  is  easily  satisfied  by  a  variety  of  typical  software  and  storage 
systems  commercially  available  and  is  not  a  limiting  factor  of  the  xCMA  system.  For 
this  reason,  it  was  removed  as  a  focal  point  for  alternatives  generation. 

With  Manage  Information  removed  as  a  key  focus,  the  primary  functions  for 
evaluation  and  consideration  are  reduced  to  Connect  with  CMA  and  Provide 
Collaboration.  These  functions  represent  the  xCMA  system’s  ability  to  physically 
connect  to  a  CMA  gateway,  identify  the  vessel  and  the  vessel’s  location,  and  to  provide 
bidirectional  communications  and  display  capability  for  all  data  and  services. 

The  product  matrix  previously  generated  was  modified  to  represent  the  decisions 
identified  above.  Changes  were  also  made  regarding  the  COMMS  category.  First,  due  to 
the  requirement  to  connect  to  a  Node  4  gateway  within  a  30  mn  range,  the  Line  of  Sight 
(LOS)  options  were  removed.  Second,  the  SATCOM  category  was  identified  as 
Commercial  only  due  to  the  unclassified  nature  of  communications  and  the  need  to 
connect  with  other  nations  and  entities  for  humanitarian  efforts.  Research  further  showed 
that  INMARSAT  does  not  handle  the  streaming  video  requirements.  In  addition,  new 
technology  was  determined  not  to  meet  a  2010  implementation  schedule  and  therefore 
would  not  be  evaluated  due  to  the  lack  of  system  specifications  available  for  evaluation. 
Upon  defining  MTE,  it  was  determined  that  MTE  was  effectively  another  form  of  a  SBC. 
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These  two  categories  were  combined  under  the  SBC  category.  The  resulting  matrix  is 
displayed  in  Table  9  and  includes  the  following  categories  of  focus;  Communications, 
Host  System,  Router/Modem,  Position  Location  Information,  Display  and  Identify.  The 
definition  of  each  category  is  defined  below. 


Table  9.  Revised  xCMA  System  Categories  anc 

Options 

COMMS 

Host  System 

Router/Modem 

PLI 

Display 

Identify 

SATCOM- 

Commercial 

Laptop 

Commercial 

GPS 

LCD 

NIC  MAC 
Address 

Wireless  (802.16 
or  equiv) 

SATCOM  - 
Military  / 
Government 

New 

Technology 

Tactical 

New 

Technology 

Other 
Hardware  / 
New 

Technology 

Software 
Definable  Radios 

SBC 

Evaluation  Criteria 

Bandwidth 

Scalable 

Properly 
interfaces 
between  Host  & 
COMMS 

Accurac 

y  =  +/- 

5  meters 

(HSI) 

Accuracy  = 
100% 

Range  >=30  nm 

Plug  &  Play 

Portable 

Expandable 

Supportable 

Maintainable 

Reliable 

•  The  COMMS  components  maintain  connectivity  to  any  CMA  gateway  within  30 
nm  from  Node  5.  It  is  a  means  that  allows  the  xCMA  system  to  communicate 
with  a  CMA  gateway.  The  communications  link  can  be  in  any  format,  such  as 
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SATCOM  or  a  wireless  point  to  point  link.  The  30  nrn  requirement  excludes 
consideration  of  Line-of-Sight  (LOS)  communications  systems. 

•  The  Host  System  is  comprised  of  components  that  function  as  the  computing  and 
storage  components  for  the  xCMA  system.  The  Host  System  also  includes  user 
interfaces  that  allow  the  xCMA  user  to  input  data,  retrieve  data,  and  communicate 
with  the  system.  It  is  understood  that  current  COTS  personal  computer  systems 
are  capable  of  handling  throughput  sufficiently  greater  than  the  required  0.128 
Mbps  of  incoming  data.  For  this  reason,  the  detailed  specific  internal  components 
of  the  Host  System  are  not  a  constraint  and  therefore  not  evaluated. 

•  The  Host  to  COMMS  interface  provides  the  functionality  to  relay  transmitted 
information  between  the  communications  components  and  the  Host  system. 

•  PLI  is  used  to  accurately  provide  own  ship  position  using  GPS  satellites.  This 
information  is  reported  to  the  CMA  and  is  available  to  the  ship  personnel.  This 
PLI  can  be  generated  automatically  based  on  the  GPS  input  or  manually  entered 
by  the  user  as  part  of  a  query  filter  that  is  sent  to  Node  4  for  UDAP  data. 

•  The  Display  function  component  is  used  to  display  CMA  data.  This  allows  the 
presentation  of  information  and  data  to  the  operator. 

•  The  Identify  function  component  is  a  requirement  to  provide  a  unique  identifier 
for  each  xCMA  system.  This  allows  accurate  logistics,  provides  some  inherent 
security  functionality,  and  is  responsible  for  providing  self-identification 
automatically  and  independently  from  the  Node  5  user.  In  this  study,  the  NIC  is 
used  to  provide  a  unique  48-bit  serial  number  called  a  MAC  address.  Another 
option  is  the  IP. 
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•  The  Router/Modem  provides  the  functionality  to  relay  transmitted  information 
and  connect  to  the  CMA  network.  It  provides  the  network  interface  going  from 
Node  4  and  Node  5  xCMA  system. 


Table  10.  Updated  List  of  Alternatives 


COMMS 

Host  System 

Router/Modem 

PLI 

Display 

Identify 

SATCOM  -  Commercial 

Laptop 

Commercial 

GPS 

LCD 

MAC/IP 

)M  -  Commercial 

New  Technology 

Commercial 

GPS 

New  Technology 

Other  HW,  new  tech 

SATCOM  -  Commercial 

SBC 

Commercial 

GPS 

LCD 

MAC/IP 

SATCOM  -  Commercial 

Mobile  Terminal 
Equipment 

Commercial 

GPS 

LCD 

Other  HW,  New  Tech 

SATCOM  - 
Military/Government 

Laptop 

Tactical 

GPS 

LCD 

MAC/IP 

SATCOM  - 
Military/Government 

New  Technology 

Tactical 

GPS 

New  Technology 

Other  HW,  new  tech 

SATCOM  - 
Military/Government 

SBC 

Tactical 

GPS 

LCD 

MAC/IP 

SATCOM  - 
Military/Government 

Mobile  Terminal 
Equipment 

Tactical 

GPS 

LCD 

Other  HW,  New  Tech 

Wireless  802.16 

Laptop 

Commercial 

GPS 

LCD 

MAC/IP 

Wireless  802.16 

New  Technology 

Commercial 

GPS 

New  Technology 

Other  HW,  new  tech 

Wireless  802.16 

SBC 

Commercial 

GPS 

LCD 

MAC/IP 

Wireless  802.16 

Mobile  Terminal 
Equipment 

Commercial 

GPS 

LCD 

Other  HW,  New  Tech 

Software  Defined  Radio 

Laptop 

Commercial 

GPS 

LCD 

MAC/IP 

Software  Defined  Radio 

New  Technology 

Commercial 

GPS 

New  Technology 

Other  HW,  new  tech 

Software  Defined  Radio 

SBC 

Commercial 

GPS 

LCD 

MAC/IP 

Software  Defined  Radio 

Mobile  Terminal 
Equipment 

Commercial 

GPS 

LCD 

Other  HW,  New  Tech 

Additional  analysis  was  conducted  to  further  refine  the  alternatives.  The  analysis 
included  research  on  available  technologies,  earlier  assumptions,  and  evaluation  of 
requirements.  Since  the  xCMA  system  is  deployed  to  foreign  allies  and  restrictions  exist 
in  the  use  of  tactical  equipment,  all  tactical  equipment  was  eliminated  from  the  list  of 
alternatives.  Software  Defined  Radios  (SDRs)  do  not  have  their  own  communications 
means.  To  use  SDRs  either  a  wireless  protocol  or  satellite  communications  system  will 
need  to  be  incorporated.  Given  this  restriction  SDRs  are  eliminated  from  the  list  of 
alternatives.  The  portability  requirement  eliminates  the  desktop  and  Cathode  Ray  Tubes 
(CRT)  due  to  bulk  and  fragility.  The  final  list  of  alternatives  is  shown  in  Table  11. 
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Table  1 1.  xCMA  System  Alternatives 


Alternatives 

COMMS 

Host  System 

Router 

/Modem 

PLI 

Display 

Identify 

1.  SATCOM- 
Laptop 

SATCOM  - 
Commercial 

Laptop 

Commercial 

GPS 

LCD 

MAC/IP 

2.  SATCOM- 
SBC 

SATCOM  - 
Commercial 

Integrated  SBC 
Mobile  Terminal 
Equipment(MTE) 

Commercial 

GPS 

LCD 

MAC/IP 

3.  Wireless- 
Laptop 

Wireless  802.16 

Laptop 

Commercial 

GPS 

LCD 

MAC/IP 

4.  Wireless-SBC 

Wireless  802.16 

Integrated  SBC 
(MTE) 

Commercial 

GPS 

LCD 

MAC/IP 

A  detailed  account  of  alternatives  generation  is  included  in  Appendix  F  and  a 
design  description  of  each  of  the  alternatives  follows. 

Alternative  1:  SATCOM-Laptop  Alternative  -  A  SATCOM  capability  is  used 
as  the  communications  means  for  connecting  to  the  CMA  network.  The  information  from 
the  host  system  laptop  is  routed  through  the  modem  and  then  transmitted  by  the  satellite 
transmitter  to  the  Node  4  satellite  receiver.  The  information  from  Node  4  is  transmitted 
by  a  satellite  transmitter  and  received  by  the  system  satellite  receiver  and  demodulated 
for  processing  by  the  host  system  laptop.  The  NIC  provides  the  system  with  a  unique 
hardware  MAC  address  for  the  system  identification.  A  COTS  GPS  receiver  will  be  used 
to  provide  system  PLI. 

Alternative  2:  SATCOM-  SBC  Alternative  -  A  SATCOM  capability  is  used  as 
the  communications  means  for  connecting  to  the  CMA  network.  The  information  from 
the  host  system  MTE  consisting  of  an  SBC,  modem/router,  power  supply,  display,  and 
input  devices  packaged  in  a  ruggedized,  transportable  container  is  routed  through  the 
demodulator  modem  and  then  transmitted  by  the  satellite  transmitter  to  the  Node  4 
satellite  receiver.  The  information  from  Node  4  is  transmitted  by  a  satellite  transmitter 
and  received  by  the  system  satellite  receiver  and  demodulated  for  processing  by  the  host 
system  MTE.  The  NIC  provides  the  system  with  a  unique  hardware  MAC  address  for 
system  identification.  A  COTS  GPS  receiver  is  used  to  provide  system  PLI. 
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Alternative  3:  Wireless  (802.16m)-Laptop  Alternative  -  A  wireless  broadband 
communications  capability  is  used  as  the  communications  means  for  connecting  to  the 
CMA  network.  The  infonnation  from  the  host  system  laptop  is  transmitted  by  the  RF 
transmitter  to  the  Node  4  RF  receiver.  The  information  from  Node  4  is  then  transmitted 
by  the  RF  transmitter  and  received  by  the  system  RF  receiver  for  processing  by  the  host 
system  laptop.  The  NIC  provides  the  system  with  a  unique  hardware  MAC  address  for 
system  identification.  A  COTS  GPS  receiver  is  used  to  provide  system  PLI. 

Alternative  4:  Wireless  (802.16m)-SBC  Alternative  -  A  wireless  broadband 
communications  capability  is  used  as  the  communications  means  for  connecting  to  the 
CMA  network.  The  information  from  the  host  system  MTE  consisting  of  an  SBC, 
modem/router,  power  supply,  display,  and  input  devices  packaged  in  a  ruggedized, 
transportable  container  will  is  transmitted  by  the  RF  transmitter  to  the  Node  4  RF 
receiver.  The  information  from  Node  4  is  transmitted  by  the  RF  transmitter  and  received 
by  the  system  RF  receiver  and  demodulated  for  processing  by  the  host  system  MTE.  The 
NIC  provides  the  system  with  a  unique  hardware  MAC  address  for  system  identification. 
A  COTS  GPS  receiver  is  used  to  provide  system  PLI. 

C.  FEASIBILITY  SCREENING 

Feasibility  Screening  facilitates  solution  selections  for  the  four  system 
alternatives.  The  purpose  of  this  activity  is  to  validate,  at  a  high  level,  the  realistic 
applicability  of  the  defined  alternative  as  a  solution  for  the  defined  problem.  This  is 
accomplished  by  evaluating  the  alternatives  using  the  previously  developed  MOEs  and 
Evaluation  Criteria.  Table  12  details  the  results  of  the  feasibility  screening  of  the  four 
identified  system  alternatives  and  a  non-materiel  solution. 
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Table  12.  xCMA  System  Feasibility  Screening 


G 

Go 

NG 

No  Go 

Green 

Meets  requirements 

Yellow  - 

Does  not  fully  meet  requirements 

Red 

Does  not  meet  requirements 

A  Non-Materiel  solution  is  included  during  feasibility  screening  to  ensure  that  all 
possible  solutions  are  considered.  The  non-materiel  solution  uses  existing  networks  and 
infrastructure  and  focuses  on  modification  of  mission  responsibilities,  operational 
concepts  and  technologies.  Existing  systems  do  not  meet  the  system  requirements  to 
provide  adequate  CMA  connectivity  to  the  disconnected  vessel  or  user.  Limited 
connectivity  could  be  provided  on  an  adhoc  basis  using  existing  Ultra  High  Frequency 
(UHF)/Very  High  Frequency  (VHF)  radio  telephones  and  possibly  messenger  services 
(small  boat  and  helicopter  delivery  of  maps,  orders).  This  does  not  provide  a  sustained 
capability  for  Node  5  to  effectively  and  efficiently  communicate  with  the  humanitarian 
operation  vessels  using  streaming  video,  text,  pictures,  e-mail,  and  chat.  This  solution 
does  not  provide  the  required  Node  5  connectivity. 

The  SATCOM  alternatives,  both  laptop  and  SBC,  satisfy  all  of  the  identified 
feasibility  criteria.  The  Wireless  (802.16m)  alternatives,  both  for  laptop  and  SBC,  satisfy 
the  feasibility  criteria  with  an  associated  risk  due  to  immaturity  of  the  standard.  This  risk 
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is  associated  with  the  range  limitations  of  the  current  802. 16e  standard.  802.16m  has 
better  mobility  and  increased  range  as  well  as  higher  throughput  rates.  However,  this 
version  (IEEE  Specification  C802.16m  -  07/003)  is  still  in  work  and  not  yet  formally 
released.  Therefore,  the  feasibility  criteria  related  to  range  and  100%  identification  are 
identified  as  risk  areas. 

D.  MODELING  &  ANALYSIS 

In  system  engineering,  a  model  is  developed  to  evaluate  the  measures  of 
effectiveness  of  a  system  being  designed.  The  created  model  is  an  incomplete 
representation  of  reality,  an  abstraction  of  the  system.  Furthermore,  the  created  models  in 
this  study  are  mathematical  abstracts  of  the  system.  A  random  number  generator  is  used 
to  model  the  propensity  of  the  system  characteristics.  The  modeling  and  analysis  phase 
includes  the  raw  data  matrix,  reliability  modeling,  and  the  throughput  modeling. 

1.  Raw  Data  Matrix 

The  Raw  Data  Matrix  highlights  several  features  of  the  xCMA  system.  The 
specific  information  is  supported  by  the  modeling  contained  in  the  following  sections. 
The  throughput  (>  Mbps)  measurement  is  a  simple  function  of  the  peak  bandwidth 
capabilities  based  on  COTS  hardware  components.  The  data  is  generated  using  hardware 
performance  values  from  multiple  SATCOM  terminal  systems,  802.16  wireless  systems, 
personal  laptop  computers,  SBCs,  router/modems,  LCD  monitors,  and  NICs. 

Some  critical  assumptions  about  the  system  include  the  following.  First,  the 
processor  speed  and  throughput  are  not  an  issue  of  concern  for  this  system  as  a  generic 
COTS  personal  computer  would  adequately  handle  processing  requirements.  Second, 
Network  Time  Allocations  are  not  under  the  control  of  the  xCMA  system  and  are  not 
used  in  the  throughput  calculations. 
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Table  13.  Raw  Data  Matrix  for  the  xCMA  system 


Evaluation 

Measure 

Alternatives 

SATCOM- 

Laptop 

SATCOM- 

SBC 

Wireless- 

Laptop 

Wireless- 

SBC 

System  Functional 
<  4  hours 

Y 

Y 

Y 

Y 

Connect  to  CMA  <10 
minutes 

Y 

Y 

Y 

Y 

The  system  will  be  up 
and  operational  at  least 
1500  hours  between 
failures.  MTBF  (hours) 

>  1500 

91.52% 

94.43% 

94.76% 

97.77% 

The  probability  that  the 
system  will  be  able  to 
meet  the  required  data 
throughput  95  %  of  the 
time 

Throughput  >  0.128 
Mbps 

99.57% 

99.57% 

99.97% 

99.97% 

Note  to  Table  13:  Estimated  data  points  are  in  PURPLE;  Hard  Data  points  are  in  Black. 


2.  Reliability  Modeling 

A  mathematical  model  was  used  to  evaluate  system  reliability.  For  reliability  to 
be  measured,  the  system  must  be  under  a  specific  set  of  maintenance  and  operational 
conditions.  Reliability  is  treated  as  a  probability  and  therefore  has  a  distribution. 

From  the  Raw  Data  Matrix,  the  MTBF  was  selected  to  measure  the  reliability  of 
the  system.  The  values  of  the  MTBF  for  the  different  system  components  were  obtained 
by  averaging  the  published  MTBF  values  obtained  from  similar  products. 

The  reliability  model  of  the  system  consists  of  five  component  categories  as 
detailed  in  Table  14.  The  reliability  for  each  component  as  a  function  of  mission  time 
(R(t))  can  be  then  calculated  by  using  the  following  equation: 

-t 

MTBF 

Eq.  (1) 

The  total  reliability  of  each  alternative  was  calculated  using  the  series  system 
formula  as  follows: 
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Rsystem  =  Rl X  Rl X  Rl X  Rl X  R5 


Eq.  (2) 


The  mission  time  of  14  days  (336  hours)  is  used  in  the  calculations  and  the  value 
for  each  component’s  reliability  is  shown  in  Table  14. 


able  14.  xCMA  System  Component  Reliability  Calculations 


Components 

System 

Reliability 

Communications:  SATCOM-Commercial 

96.36% 

Communications:  Wireless  802.16 

99.76% 

Host  System:  Laptop 

96.69% 

Host  System:  Single  Board  Computer  (MTE) 

99.77% 

Router/Modem:  Commercial 

99.95% 

Display:  LCD 

98.52% 

Identify:  MAC  Address 

99.76% 

To  determine  the  simulated  system  alternative  reliabilities,  the  components  of 
each  alternative  were  grouped  together.  Each  alternative  was  simulated  using  Microsoft 
Excel  with  a  random  function.  Each  model  was  simulated  with  300  replications  to  reach 
result  stability  and  ensure  a  95%  confidence  interval.  The  results  are  summarized  in 
Table  15.  The  detailed  simulated  results  are  shown  in  Appendix  G. 


Table  15.  Simulated  xCMA  System  Reliability  Results  for  the  Alternatives 


Alternatives 

Reliability  Simulations  Results 

SATCOM-Laptop 

91.52% 

SATCOM-SBC 

94.43% 

Wireless-Laptop 

94.76% 

Wireless-SBC 

97.77% 

The  simulated  system  reliability  values  in  Table  15  above  were  then  used  to 
calculate  the  system  MTBF  values.  The  system  MTBF  results  are  shown  in  Table  16  and 
are  used  in  conjunction  with  the  MTBF  Multi-Attribute  Utility  Theory  (MAUT)  to 
determine  a  weighted  score  for  each  of  the  alternatives. 
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Table  16.  Simulated  xCMA  System  MTBF  Results  for  the  Alternatives 


Alternatives 

Simulated  MTBF  Results  (hrs) 

SATCOM-Laptop 

3,794 

SATCOM-SBC 

5,863 

Wireless-Laptop 

6,246 

Wireless-SBC 

14,880 

3.  Throughput  Modeling 

Throughput  is  one  evaluation  measure  in  the  Raw  Data  Matrix.  For  the  xCMA 
system  modeling  and  simulation,  throughput  is  referred  to  transmission  performance  of 
data  and  is  measured  by  transmitted  or  received  data  during  a  certain  period  of  time.  The 
throughput  of  a  connection  depends  on  the  Central  Processor  Unit  (CPU),  memory,  and 
any  other  processing  components  that  are  linked  together.  Throughput  is  a  measure  in 
megabits  per  second  (Mbps).  The  requirement  for  the  xCMA  system  has  been  defined  by 
the  stakeholders  as  greater  than  or  equal  to  0.128  Mbps. 

To  measure  and  analyze  the  throughput  of  the  system,  a  model  similar  to  that  of 
reliability  was  used.  The  system  components  are  connected  in  series. 

The  throughput  model  data  is  based  on  research  of  similar  systems  in  the 
commercial  sector.  Each  alternative’s  components  are  assigned  with  average  values  of 
throughput  from  manufacturer’s  published  values.  Since  the  model  was  created  with 
components  connected  in  series,  the  overall  system  throughput  could  be  determined  by 
the  subcomponent  that  has  the  lowest  throughput  for  each  alternative.  This  can  be 
represented  as  follows: 

TSys,,n  =  Mini  Ti’TvTvT*,!,)  Eci  ^ 

Based  on  the  system  throughput  equation  above,  each  of  the  components  has  a 
calculated  throughput  value  as  shown  in  Table  17.  The  detailed  throughput  calculations 
and  results  are  shown  Appendix  G. 
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Table  17.  xCMA  System  Component  Throughput  Calculations 


Component 

Throughput 

(Mbps) 

Communications:  SATCOM-Commercial 

0.235 

Communications:  Wireless  802.16 

100 

Host  System:  Laptop 

322 

Host  System:  SBC  (MTE) 

2,008 

Router/Modem:  Commercial 

3.729 

Display:  LCD 

1,064.960 

Identify:  MAC  Address 

235.000 

The  model  uses  a  random  exponential  arrival  and  service  distribution.  The 
evaluation  measures  from  the  Raw  Data  Matrix  of  the  xCMA  system  alternatives  are 
simulated  and  captured  for  comparison.  Each  component’s  throughput  is  simulated  with 
30  replications  (500  runs  each).  The  throughput  results  are  shown  in  Table  18  and 
detailed  results  are  shown  in  Appendix  G.  The  results  indicate  that  all  alternatives  meet 
the  minimum  required  throughput  of  0. 128  Mbps.  Also,  the  simulated  results  support  the 
evaluation  measures  in  the  Raw  Data  Matrix. 


Table  18.  Throug 

lput  Simulations  Results  for  xCMA  System  Alternatives. 

Alternative 

Required 
Throughput  Met? 

The  probability  that  95  %  of  the  time 
Throughput  >  0,128  Mbps 

SATCOM-Laptop 

Yes 

99.57% 

SATCOM-SBC 

Yes 

99.57% 

Wireless-Laptop 

Yes 

99.97% 

Wireless-SBC 

Yes 

99.97% 
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V.  DECISION  MAKING  AND  RECOMMENDATIONS 


A.  DECISION  MAKING 

The  final  phase  in  the  tailored  systems  engineering  process  is  decision  making. 
This  phase  consists  of  Analysis  of  Alternatives  and  Recommendation  as  shown  in  Figure 
19. 


xCMATask 

Assignment 

(SOW  &  Scenario) 


I 


CH  1 

Appendix  A  -  SOW 


Literature  Review 

Stakeholder  Analysis 

I 

i 

Derived  Requirements 

Stakeholder 

Requirements 

System  Requirements 


Needs  Analysis  & 
Requirements  Definition 


CH  3 

Appendix  C  Input/Output 
Analysis 

Appendix  D  FFBD 
Appendix  E  IDEF  0 
Appendix  F  QFD  (Details) 


Appendix  B:  Stakeholder 
Feedback 


Input/Output  Analysis 


Functional  Analysis 
(Functional 
Decomposition, 
FFBD  &  IDEFO) 


Functional  Hierarchy 
(weighting  factors  & 
evaluation  measures) 


Quality  Functional 
Deployment  (QFD) 


Value  System  Design 


Appendix  G  Alternatives 
CH  ^  Appendix  H  Reliability  Modeling 
Appendix  I  Throughput  Modeling 


Alternatives  Generation  (Dev 
of  Alternatives  (Zwicky)  & 
Feasibility  Screening, 
Recommended  Alternatives) 


Appendix  J  Acronym  List 
Appendix  K  References 
Appendix  L  Distribution  List 


Modeling  &  Simulation  (Raw 
Data  Matrix,  Reliability  & 
Throughput  Model) 


Design  &  Analysis 


Analysis  of 
Alternatives 

Recommendation 

(Decision  Matrix) 

Decision  Making 


Figure  19  Decision  Making  Phase.  This  figure  highlights  the  Decision  Making  activities 
completed  in  the  tailored  system  engineering  process. 

The  purpose  of  these  activities  is  to  analyze  the  viable  alternatives  from  the 
Design  and  Analysis  phase  and  to  numerically  score  the  alternatives  so  that  a  final 
recommendation  can  be  given  to  the  stakeholders.  The  analysis  of  alternatives  includes 
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the  development  of  MAUT  scores,  a  decision  matrix,  and  sensitivity  analysis.  The  results 
from  these  work  products  were  then  used  in  the  final  recommendation. 

1.  Decision  Matrix 

The  Decision  Matrix  is  the  result  of  the  application  of  global  weights  and  MAUT 
scores  on  the  four  xCMA  system  alternatives.  MAUT  provides  a  systematic,  objective, 
and  quantitative  way  of  identifying  and  analyzing  multiple  variables  and  objectives  to 
form  a  common  basis  for  arriving  at  a  decision.  The  MAUT  utilities  are  captured  from 
the  stakeholders  with  the  level  of  importance  of  each  utility  reflecting  the  preference  of 
the  stakeholders. 

MTBF  was  one  of  the  evaluation  measures  examined  and  applied  with  MAUT. 
Research  of  similar  current  systems  provided  MTBF  data  for  each  system  component. 
This  data  was  statistically  analyzed  and  the  mean  value  was  used  in  the  simulation.  Table 
19  provides  the  values  from  the  simulation.  This  data  was  used  to  extract  the 
corresponding  value  from  the  MAUT  curve  as  displayed  in  Figure  20. 


Table  19.  xCMA  System  Alternatives  Mean  Time  Between  Failure  Comparison 


Ranking 

Alternative 

MTBF  (Hrs) 

Symbol 

1 

Wireless  -  SBC 

14,880 

O 

2 

Wireless  -  Laptop 

6,246 

o 

3 

SATCOM-SBC 

5,863 

* 

4 

SATCOM-Laptop 

3,794 

A 

Table  19  summarizes  the  outcome  of  the  modeling  and  simulation  results  for  each 
alternative.  These  results  were  based  on  existing  systems  reliability  data.  The  results  are 
ranked  according  to  their  resulting  mean  time  between  failure  data.  A  MTBF  of  equal  or 
greater  than  1500  hours  was  determined  to  be  the  minimum  requirement  based  on 
standard  MIL-PRF-28800F. 
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MTBF  for  xCMA  System  Alternatives 


Figure  20.  MTBF  MAUT  Utility  for  xCMA  System  Alternatives.  The  MAUT  tool 
details  the  relative  comparison  of  the  four  system  options  based  on  mean  time  between 
failure. 

Throughput  was  the  second  evaluation  measure  examined.  Research  of  similar 
current  systems  provided  throughput  data  for  each  system  component  as  in  Table  20. 
This  data  was  statistically  analyzed  and  the  mean  value  was  used  in  the  simulation.  The 
components  for  each  alternative  were  reviewed.  The  component  with  the  smallest 
throughput  was  used  to  extract  a  MAUT  value  from  the  utility  curve  as  shown  in  Figure 
21. 


Table  20.  xCMA  System  Alternatives  Throughput  Comparison 


Ranking 

Alternative 

Throughput 

(Mbps) 

Symbol 

1  and  2 

Wireless  -  SBC  and 
Wireless  -  Laptop 

3.729 

o  o 

3  and  4 

SATCOM-Laptop  and 
SATCOM-SBC 

0.235 

A  * 

Table  20  summarizes  the  outcome  of  the  modeling  and  simulation  results  for  each 
alternative.  These  results  were  based  on  throughput  data  from  existing  systems.  The 
results  are  ranked  according  to  their  resulting  throughput.  The  minimum  throughput 
acceptable  was  determined  to  be  equal  to  or  greater  than  0. 128  Mbps  based  on 
stakeholder  feedback. 
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Throughput  for  xCMA  System  Alternatives 

Minimum 
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Figure  21.  MAUT  translation  of  throughput  for  the  xCMA  system  alternatives.  The 
MAUT  values  for  throughput  are  mapped  into  a  0  to  100  point  scale. 


Technology  Readiness  Level  (TRL)  was  the  third  evaluation  measure  examined. 
Research  was  performed  on  each  of  the  alternatives  and  based  on  the  results,  the  TRL 
levels  were  assigned  as  in  Table  21.  The  MAUT  values  were  extracted  from  utility  curve 
in  Figure  21. 


Table  2 1 .  xCMA  System  Alternatives  TRL  Comparison 


Ranking 

Alternatives 

TRL 

Symbol 

1  and  2 

SATCOM-Laptop  and 
SATCOM-SBC 

9 

A  * 

3  and  4 

Wireless  -  SBC  and 
Wireless  -  Laptop 

6 

o  o 

Table  21  summarizes  the  results  of  the  TRLs  for  each  alternative.  These  results  were 
based  on  research.  To  mitigate  risk  a  decision  was  made  to  use  a  system  with  TRL  equal 
or  greater  than  6. 
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xCM  A  System  Alternatives 


TRL 


Figure  22.  MAUT  translation  of  TRL  for  the  xCMA  system  alternatives.  The  MAUT 
values  for  TRL  are  mapped  from  0  to  9  into  a  0  to  100  point  scale. 

The  Decision  Matrix  captures  and  uses  weighting  factors  from  the  stakeholders  to 
bring  out  the  level  of  importance  of  each  evaluation  measure.  The  weights  of  all 
evaluation  measures  are  normalized  to  a  total  value  of  100%. 

Once  the  MAUT  utilities  and  global  weights  are  determined,  the  results  from  the 
Raw  Data  Matrix  are  translated  into  the  Decision  Matrix.  The  score  of  each  evaluation 
measure  of  the  xCMA  system  is  extracted  from  the  corresponding  MAUT  utility  curve, 
as  in  Figure  20  to  Figure  22,  to  capture  the  objective  score  for  each  of  the  four  xCMA 
system  alternatives.  The  MAUT  scores  are  then  weighted  using  the  corresponding  global 
weight  to  provide  the  final  score  represented  in  the  Decision  Matrix.  The  scores  of  each 
xCMA  system  alternative  are  then  summed  to  detennine  the  final  total  score  as  shown  in 
Table  22. 
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Table  22.  Decision  Matrix  for  the  xCMA  system 


Raw  Data  Matrix 

Decision  Matrix 

Evaluation 

Measures 

Alternatives 

Evaluation 

Measures 

Global 

Weight 

Alternatives 

SATCOM- 

Laptop 

SATCOM- 

SBC 

Wireless- 

Laptop 

Wireless- 

SBC 

SAT  COM-Laptop 

SATCOM-SBC 

Wireless-Laptop 

Wireless-SBC 

MAUT 

Score 

Weighted 

MAUT 

Score 

Weighted 

MAUT 

Score 

Weighted 

MAUT 

Score 

Weighted 

System 
Functional  < 
4  hours 

Y 

Y 

Y 

Y 

System 
Functional  < 

4  hours 

0.1 

100 

10 

100 

10 

100 

10 

100 

10 

Connect  to 

CMA  <  10 

minutes 

Y 

Y 

Y 

Y 

Connect  to 

CMA  <  10 

minutes 

0.1 

100 

10 

100 

10 

100 

10 

100 

10 

MTBF  > 

1500  hrs 

91.52% 

94.43% 

94.76% 

97.77% 

MTBF  > 

1500  hrs 

0.25 

93 

23.25 

98 

24.5 

98 

24.5 

100 

25 

95% 

Probability 

that 

Throughput 

>0.128 

Mbps 

99.57% 

99.57% 

99.97% 

99.97% 

95% 

Probability 

that 

Throughput 

>0.128 

Mbps 

0.25 

92 

23 

92 

23 

100 

25 

100 

25 

TRL  >  6 

0.3 

98 

29.4 

98 

29.4 

80 

24 

80 

24 

Total  Value  Score 

95.65 

93.50 

94.00 

The  Total  Value  Scores  resulted  in  the  SATCOM-SBC  system  alternative  having 
the  highest  value  at  96.90  out  of  100  possible  points.  The  second  highest  value  is  95.65 
for  the  SATCOM-Laptop  system  alternative.  The  third  alternative,  Wireless-SBC,  rates 
lower  at  94.00.  The  Wireless-Laptop  system  alternative  has  the  lowest  score  at  93.50. 
The  results  from  the  alternative  scoring  indicate  the  SATCOM-SBC  option  is  the 
recommended  solution,  however,  the  results  also  indicate  that  all  system  alternatives 
exceed  the  evaluation  criteria. 

2.  Sensitivity  Analysis 

During  the  sensitivity  analysis  process,  the  evaluation  criteria  are  defined  and 
assessed  with  respect  to  each  of  the  alternatives.  The  evaluation  criterion  is  detailed  in 
the  sections  below  and  the  value  charts  are  based  on  MAUT. 

System  Functional  (<  4  hours):  This  evaluation  measure  is  weighted  by 
assigning  a  numerical  value  between  0  and  100  to  the  estimated  xCMA  system  set 
up  time.  All  four  alternatives  scored  satisfactorily,  and  met  the  operational 
requirements. 

Connect  to  CMA  (<  10  minutes):  This  evaluation  measure  is  weighted 
by  assigning  a  numerical  value  between  0  and  100  to  the  estimated  time  from 
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xCMA  system  tum-on  to  actual  connection  to  the  CMA.  All  four  alternatives 
scored  satisfactorily,  and  met  the  operational  requirements. 

Required  Throughput  (=95%):  This  evaluation  measure  is  weighted  by 
assigning  a  numerical  value  between  0  and  100  to  the  required  throughput 
percentage;  the  higher  the  percentage  of  throughput  above  95%,  the  higher  the 
score.  All  four  alternatives  scored  satisfactorily,  and  met  the  operational 
requirements.  The  alternatives  including  the  Wireless  option  scored  100. 

MTBF  (hours):  This  evaluation  measure  is  weighted  by  assigning  a 
numerical  value  between  0  and  100  to  the  MTBF;  the  higher  the  MTBF,  the 
higher  the  score.  All  four  alternatives  scored  satisfactorily,  and  met  the 
operational  requirements. 

Technology  Readiness  Level  (TRL)  (  >  6):  This  evaluation  measure  is 
weighted  by  assigning  a  numerical  value  between  0  and  100  based  on  the  TRL 
values  of  0  to  9.  The  SATCOM  based  systems  both  scored  98  and  the  wireless 
systems  scored  an  80. 


B.  RECOMMENDATION 

Through  the  culmination  of  the  efforts  of  applying  the  tailored  systems 
engineering  process  and  using  the  results  of  the  tools  and  activities  leading  to  the 
generation  of  the  decision  matrix  and  the  sensitivity  analysis  the  resulting 
recommendation  indicates  all  four  options  are  viable  systems  and  are  capable  of 
providing  a  solution  to  the  problem.  The  Satellite  Communication  (SATCOM)  with  a 
Single  Board  Computer  (SBC)  alternative,  however,  is  the  higher  ranked  configuration 
for  extending  CMA  to  a  disconnected  node  in  support  of  humanitarian  efforts.  In  this 
approach  a  SATCOM  capability  is  used  as  the  communications  means  for  connecting  to 
the  CMA  network.  The  information  from  the  host  system  consisting  of  an  SBC, 
modem/router,  power  supply,  display,  and  input  devices  packaged  in  a  ruggedized, 
transportable  container  is  routed  through  the  modulator  demodulator  (modem)  and  then 
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transmitted  by  the  satellite  transmitter  to  the  Node  4  satellite  receiver  (Node  4  details  are 
to  follow).  The  information  from  Node  4  is  transmitted  by  a  satellite  transmitter  and 
received  by  the  system  satellite  receiver  and  demodulated  for  processing  by  the  host 
system.  The  Network  Interface  Card  (NIC)  provides  the  system  with  a  unique  hardware 
Media  Access  Control  (MAC)  address  for  system  identification.  A  Commercial-Off- 
The-Shelf  (COTS)  Global  Positioning  System  (GPS)  receiver  is  used  to  provide  system 
Position  Location  Infonnation  (PLI). 

C.  FUTURE  ACTIVITIES 

The  systems  engineering  process  focuses  on  technology  research,  analysis,  and 
solutions.  Cost  with  regards  to  technology  tradeoffs  was  not  performed  on  the  generated 
alternatives  or  considered  in  the  decision  making.  Because  all  the  evaluated  alternatives 
are  considered  to  be  viable  options,  future  cost  analysis  should  be  conducted. 

The  current  802. 16e  range  capability  lacks  the  30  nrn  requirement  by  4.5  miles. 
One  capability  proposed  in  the  802.16m  standard  states  improved  range,  which  has  yet  to 
be  defined.  It  is  an  assumption  that  the  proposed  increase  in  range  will  meet  the  30  mn 
requirement.  The  standard  is  scheduled  to  be  completed  by  2009.  The  802.16m 
technology  is  a  viable  future  option,  once  the  TRL  matures  and  systems  become  readily 
available. 

The  SBC  requires  further  integration  and  this  was  not  addressed  in  the  evaluation 
of  the  system.  Integration  effort  in  this  alternative  could  lead  to  additional  technology 
requirements  and  costs.  These  considerations  are  disadvantages  for  this  particular 
alternative.  Therefore,  the  laptop  solution  may  be  a  more  viable  current  implementation. 
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APPENDIX  A.  STATEMENT  OF  WORK 


Comprehensive  Maritime  Awareness  for  Non-CMA  Connected  Nodes 


Scope: 

This  task  investigates  the  extension  of  Comprehensive  Maritime  Awareness  to  non 
connected  nodes  to  facilitate  continued  infonnation  sharing.  The  specific  focus  will  be 
on  the  architecture  required  to  ensure  that  previously  non-CMA  connected  nodes  and  end 
users  are  active  participants  in  CMA.  The  following  will  be  the  primary  scenarios  used 
for  validating  the  candidate  architecture. 

-  Non-CMA  Connected  Vessel  -  Connectivity  of  planned,  non  operative  CMA  node 

•  Coast  Guard  small  boat  that  doesn't  have  capability  to  do  (fusion,  MDA 
CONOPS  objectives) 

•  Red  Cross  type  ship;  Navy  Hospital  Ship 

•  Commercial  ship 


Assumptions: 

The  following  assumptions  are  made  regarding  this  effort. 

-  CMA  systems  exists  and  are  fully  operational  (Nodes  1  through  Node  4) 

-  Node  4  will  use  existing  fusion  and  operational  capabilities  to  enable 
disadvantage  node  connection  to  the  CMA.  It  will  be  responsible  for  its  own 
information  and  data  flow  to  the  CMA  as  well  as  the  info  from  the  previously 
non-connected  Node  5. 

-  Connections  will  involve  unclassified  data  only 

-  Regional  gateway  will  be  MHQ  with  MOC  (Node  3) 

-  Connectivity  between  Node  4  and  Node  5  will  be  provided  by  a  “black  box” 
connectivity  system. 


Guidance  for  Architecture: 

-  Use  CMA  OV-1  and  OPNAV  N6  OV-1  (from  MDA  N6  Brief)  as  a  high-level 
view  and  assumption  to  their  architecture  development. 

-  Also  use  MHQ  with  MOC  OV-1 

-  Size,  power  and  weight  constraints  similar  to  small  vessels  and  assumes  max 
distance  to  node  4  of  30  nm 


CDD  Guidance: 

Assume  CMA  capabilities  are  there.  Develop  CDD  to  support  CMA  Node  4  and  Node  5, 
as  defined  above,  under  the  Fleet  CMA  CONOPS/Architecture. 

-  The  work  product  will  be  an  appendix  and  will  be  delivered  in  lieu  of  Chapters  4 
&  5  of  the  Project  Report 
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-  The  ICD  requirement  for  the  MDA  CDD  was  fulfilled  with  the  following 
documents: 

-  National  CONOPS  to  Achieve  Maritime  Domain  Awareness 

-  Fleet  CONOPS  for  Maritime  Domain  Awareness 

-  Fleet  MHQ/MOC  CONOPS 

-  GMII  CONOPS 

-  CMA  Implementing  Directive  (Joint  Requirements  Oversight  Council  Approved) 

-  CMA  CONOPS 


CDD  Guidance: 

Definitions: 

The  following  definitions  will  be  used  for  Node  4  and  Node  5  for  this  effort. 

Node  5:  Vessel  with  sensor  capabilities  (none  to  extensive)  and  having  either  limited  or 
no  CMA  connectivity 

Node  5:  A  Node  5  participant  is  a  user  or  vessel  with  sensor  capabilities  varying  from 
none  to  extensive,  that  does  not  have  a  direct  connection  to  the  existing  CMA  network. 
This  node  will  be  limited  to  sending  request  for  area  information,  providing  aperiodic 
manual  sensor  or  visual  information  and  receiving  updates  from  Node  4.  The  following 
characteristics  apply: 

-  No  data  fusion  capability 

-  Limited  sensor  data  available 

-  Provides  input  into  CMA  network  via  node  4  connection 

-  Receives  guidance  from  CMA  network  regarding  mission  specific  info 

Node  4:  The  Node  4  asset  will  be  the  gateway  between  the  Node  5  and  the  CMA 
network.  It  will  be  provide  connectivity  between  Node  5  and  all  other  CMA  nodes.  It 
will  be  capable  of : 

-  Collecting  CMA  data,  including  data  from  Node  5  and  providing  it  to  the  CMA 
network 

-  Fusing  maritime  data/info,  CMA  and  Node  5  using  existing  CMA  fusion 
capabilities 

-  Assessing  threats;  alerts 

-  Sharing  threats  &  picture;  including  providing  the  UDAP  for  Node  5 


Technical  Requirements: 

Statement  of  Work: 

-  Characterization  of  the  Problem  Space:  the  identification  of  current  system 
(“as  is”)  and  the  deficiencies  as  well  as  constraints  inherent  in  the  operational 
environment  in  order  to  characterize,  understand  and  bound  the  problem  space. 
The  project  team  will  identify  and  translate  CMA  functions  from  the  Fleet  MDA 
CONOPS,  National  MDA  CONOPS,  and  the  CMA  CONOPS  into  system 
engineering  structures  (“to  be”  concepts,  data  models,  and  architecture  functions, 
requirements,  solutions)  necessary  to  develop  the  node  4  and  node  5  connectivity 
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concept.  The  project  team  will  evaluate  the  functions,  requirements  and 
architectures  in  support  of  the  integration  of  CMA  requirements. 

1.  Functional  Representation  And  Decomposition:  the  representation  of  system 
concepts  through  functional  description  and  decomposition  as  well  as  system 
architecting  (DoDAF  models)  and  simulation.  Develop  representations,  models, 
and  methods  to  express  automated  resource  collaboration  concepts  and 
information  sharing  solutions  in  the  context  of  the  CMA  architecture  and 
domains.  The  project  team  will  develop  a  system  model  and  architecture  to 
evaluate  the  performance  of  the  proposed  architecture. 

2.  Analysis  of  Key  Capabilities:  the  identification  and  evaluation  of  technologies 
and  research  areas  key  to  the  integration  of  Nodes  4  and  5  into  the  CMA  concept. 

3.  Deliverables: 

a.  Project  Report  -  Will  include  chapters  1-5. 

b.  In  Progress  Review  -  Status  review  provided  end  of  Quarter  2. 

c.  Final  Presentation 
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APPENDIX  B.  INPUT/OUTPUT  ANALYSIS 


The  Input/Output  analysis  was  performed  as  a  first  step  in  defining  the  needs  and 
constraints  for  the  xCMA  system.  The  complete  input/output  analysis  is  shown  in  Figure 
B-l.  The  purpose  of  this  diagram  is  to  indicate  the  flow  of  information  between  the 
inputs  and  the  transfonnation  of  those  inputs  into  outputs  for  the  xCMA  system.  The 
Input/Output  analysis  concentrates  on  defining  the  requirements  and  not  the  functions  of 
the  system  or  functional  requirements.  The  required  inputs  were  broken  down  into 
controllable  and  uncontrollable  inputs  and  the  related  outputs  were  intended  and 
unintended,  or  by-products.  Intended  inputs  are  those  inputs  that  are  determinable  or 
controlled  and  the  unintended  inputs  cannot  be  controlled.  Desired  outputs  are  shown  as 
intended  outputs  and  the  by-products  are  identified  as  undesired  outputs.  The  desired 
outputs  are  the  main  purpose  for  the  xCMA  system  and  ultimately  define  or  meet  the 
needed  requirements.  During  the  input/output  analysis,  constraints  were  identified  while 
still  meeting  the  requirements  of  the  effective  need  statement. 
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•  Validated  Authentication 

•  Scalable  bandwidth  on  Demand 
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Uncontrollable 
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attacks 

•  Security  Violation  (unintended 
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By-Product 
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•  Too  much  Information 

•  Unusable  Information 
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•  Security  Violation  (unintended  classified 
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Figure  B-l.  xCMA  Input-Output  Analysis.  The  Input/Output  analysis  was  perfonned  as  a  first 
step  in  defining  the  needs  and  constraints  for  the  xCMA  system.  The  purpose  of  this  diagram  is 
to  indicate  the  flow  of  information  between  the  inputs  and  the  transformation  of  those  inputs  into 
outputs  for  the  xCMA  system. 
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APPENDIX  C.  FUNCTIONAL  FLOW  BLOCK  DIAGRAM  (FFBD) 


In  order  to  perform  a  basic  functional  decomposition  of  the  system  a  FFBD  was 
constructed.  This  FFBD  decomposed  each  level,  or  basic  function  to  better  understand 
how  the  information  flows  through  the  proposed  system.  Inputs  to  the  system  enter  from 
the  left  and  exit  to  the  right  as  outputs.  The  functional  flow  block  diagram  is  shown  in 
Figures  C-l  through  Figure  C-7.  Figure  C-l  shows  the  main  functions  of  the  proposed 
xCMA  system.  Figure  C-2  shows  the  flow  of  information  for  the  Connect  with  CMA 
function.  Figure  C-3  shows  the  flow  of  information  for  the  Provide  Collaboration 
function  and  Figure  C-7  shows  the  flow  of  information  for  the  Manage  Information 
function.  The  Provide  Collaboration  function  has  several  subsets,  or  subnodes,  which  are 
identified  as  Receive,  Send,  and  Display  Information  and  are  shown  in  Figure  C-4,  Figure 
C-5  and  Figure  C-6,  respectively. 

“And”  connectors  are  used  to  show  parallel  functions  that  are  accomplished  and 
“Or”  connectors  are  used  where  the  flow  of  information  can  proceed  any  one  function. 
The  flow  of  information  is  always  shown  to  go  from  left  to  right.  Decomposition  of 
functions  is  shown  as  references. 
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Connect  with 
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Collaboration 

Information 

Figure  C-l.  xCMA  Main  Functions  Functional  Flow  Block  Diagram.  This  figure  depicts 
the  top  level  functions  of  the  xCMA  system  in  a  functional  flow  block  diagram  format 
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Connection 
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Figure  C-2.  xCMA  Connect  with  CMA  Functional  Flow  Block  Diagram.  This  figure 
depicts  the  Connect  with  CMA  functions  of  the  xCMA  system  in  a  functional  flow  block 
diagram  format 
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Figure  C-3.  xCMA  Provide  Collaboration  Flow.  This  figure  depicts  the  Provide 
Collaboration  Flow  in  the  xCMA  system  in  a  functional  flow  block  diagram  format. 
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Figure  C-4.  xCMA  Subnode  Receive  Information  Functional  Flow  Block  Diagram.  This 
figure  depicts  the  Receive  Infonnation  portion  of  the  xCMA  system  in  a  functional  flow 
block  diagram  format. 
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2.2.5 
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Services 

Figure  C-5.  xCMA  Subnode  Send  Information  Flow.  This  figure  depicts  the  Send 
Information  portion  of  the  xCMA  system  in  a  functional  flow  block  diagram  format. 
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Figure  C-6.  xCMA  Subnode  Display  Infonnation  Functional  Flow  Block  Diagram.  This 
figure  depicts  the  Display  Information  portion  of  the  xCMA  system  in  a  functional  flow 
block  diagram  format. 
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Figure  C-7.  xCMA  Manage  Information  Functional  Flow  Block  Diagram.  This  figure 
depicts  the  Manage  Information  portion  of  the  xCMA  system  in  a  functional  flow  block 
diagram  format. 
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APPENDIX  D.  IDEFO 


A  functional  model  of  the  xCMA  system  was  constructed  using  IDEFO.  The 
IDEFO  model  structurally  reflects  the  system  functions  and  shows  the  flow  of  information 
connecting  these  functions.  The  basic  functions  used  in  the  IDEFO  model  were 
previously  identified  in  the  FFBD.  The  IDEFO  model  identifies  input  data  and  the 
processing  as  well  as  analysis  that  takes  place  as  part  of  the  model.  Identified  are  also 
inputs  that  are  required  from  the  User  at  the  disconnected  vessel,  information  that  is  sent 
via  the  xCMA  system  to  the  gateway  node,  and  information  that  is  received  via  the 
gateway  node.  This  aids  in  determining  the  requirements  for  processing  and  receiving  of 
the  various  kinds  of  data  as  well  as  operator  interfaces  that  are  incorporated  into  the 
design.  The  various  kinds  of  information  that  transfer  between  the  xCMA  system  and  the 
gateway  node  are  then  used  to  calculate  requirements  for  bandwidth  and  for  optimization 
of  the  overall  system.  The  model  further  aids  in  identifying  requirements  that  satisfy  the 
effective  need  and  validation  of  these  requirements  through  stakeholder  inputs.  The 
complete  IDEFO  model  is  shown  on  Pages  D3  through  DIO. 
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Figure  D-l.  xCMA  Context  Diagram  (A-0).  The  A-0  diagram  shows  the  external  interface  for  the  xCMA  Node  5. 
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Figure  D-2.  Extend  CMA  to  Disconnected  Node  5  (AO).  The  AO  diagram  shows  the  detailed  interface  of  the  CMA  to  Node  5. 
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Figure  D-3.  xCMA  Connect  with  CMA  (Al).  The  A1  diagram  details  the  interface  between  the  sub  functions  of  the  Connect  with 
CMA  function. 
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Figure  D-3.  Provide  Collaboration  within  xCMA  system  (A2).  The  A2  diagram  details  the  interface  between  the  main  functions  of  the 
xCMA  system. 
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Figure  D-4.  Receive  Information  (A21).  The  A21  diagram  drills  down  into  the  subfunctions  of  receive  information  function. 
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Figure  D-6.  xCMA  System  Send  Information  (A22).  The  A22  diagram  drills  down  to  the  subfunctions  of  the  Send  Information 
function. 
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Figure  D-7.  xCMA  System  Display  Information  (A23).  The  A23  diagram  drills  down  to  the  subfunctions  of  the  Display  Information 
function. 
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Figure  D-7.  xCMA  Manage  Infonnation  (A3).  The  A3  diagram  drills  down  to  the  subfunctions  of  the  Manage  Information  function. 
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APPENDIX  E.  QUALITY  FUNCTIONAL  DEPLOYMENT 


In  an  effort  to  facilitate  responsiveness  to  customer  requirements,  a  QFD  diagram 
was  performed.  The  development  of  the  QFD  ensures  that  all  the  customer  requirements 
are  identified  and  applied  in  the  most  appropriate  manner  to  address  the  problem.  The 
QFD  results  aided  in  a  common  understanding  of  requirements  between  all  the 
stakeholders  and  identified  the  most  important  requirements  to  be  met  by  the  xCMA 
system. 

Once  the  QFD  relationships  were  established,  weighting  factors  were  assigned  to 
each  of  the  requirements.  The  weighting  factors  identified  the  requirements  that  were 
used  as  MOEs  for  the  system  performance.  The  QFD  also  presented  the  customer 
requirements  in  engineering  terms. 
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Figure  E-l.  QFD  Representation  of  System  Level  Requirements.  This  QFD  depicts  the 
interactions  between  the  system  level  requirements  and  relationship  between  the  system  level 
requirements  and  customer  requirements. 
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Relationship 


interactions  between  the  system  functions  and  subfunction  elements.  Also,  the  QFD  shows  the 
relationship  between  the  system  level  requirements  and  system  functions  and  subfunctions. 
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Figure  E-3.  QFD  Representation  of  System  Functions  and  Sub  functions  and  Evaluation 
Measures.  This  QFD  depicts  the  interactions  between  the  evaluation  measure  elements.  The 
QFD  also  shows  the  relationship  strength  between  the  evaluation  measures,  and  system  functions 
and  subfuntions. 
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APPENDIX  F.  ALTERNATIVES  GENERATION 


Through  research,  brainstorming  and  brain-writing,  a  list  of  possible  alternatives 
were  considered.  The  alternatives  were  generated  by  focusing  on  the  functional  model 
and  the  QFD  results,  keeping  in  mind  the  requirements  listed  in  each  of  these  analysis. 
The  initial  set  of  alternatives  was  generated  from  a  table  of  options.  Options  to  meet  the 
requirements  were  categorized  into  COMMS,  a  host  system,  host  to  communications 
interface,  software  services,  PLI,  display,  identify,  user  interfaces,  storage  and 
deployability.  The  initial  list  of  options  is  shown  in  Table  F-l.  From  this  set  of  options, 
alternatives  were  generated  that  make  use  of  each  of  these  options.  The  initial  list  of 
alternatives  is  shown  in  Table  F-2. 
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Table  F- 1 .  Initial  List  of  Options 


COMMS 

Host  System 

HOST  to  COMMS 

Interface 

PLI 

Display 

Identify 

User  Interfaces 

Storage 

Deployability 

INMARSAT(L-Band) 

PDA 

Tactical  Internal 

Router 

DGPS  -  Internal 

Color 

NIC  (Network 
Interface  Card) 

keyboard 

Internal 

Man 

KU  Band  SATCOM 

Tactical  External 

Router 

touch  screen 

UHFSATCOM 

Laptop 

Commercial 

Internal  Router 

Multiple 

Displays 

trackball 

HF-LOS 

Commercial 

External  Router 

DGPS- External 

IP  Based 

mouse 

External 

Ship 

UHF-LOS 

Desktop 

voice 

recognitions 

VHF-LOS 

Tactical  Internal 

Modem 

GPS  -  External 

Size 

mic  /  speakers 

Wireless 

(802.11/802.16) 

PC  Based 

Tactical  External 

Modem 

Other  Hardware 

headset 

Remote 

camera 

Helo 

TSAT 

Rack  mounted  SBCs 

Commercial 

Internal  Modem 

GPS  -  Internal 

Readable  in 
bright  light 

bio  recognition 

Removable 

New  Technology 

Commercial 

External  Modem 

card  reader 

Software  Definable 

Radios 

Mobile  Terminal 
Equipment 

Evaluation  Criteria 

Bandwidth 

Scalable 

Properly  interfaces 
between  Host  & 

COMMS 

Accuracy  =  +/- 10 
meters 

(HSI) 

Accuracy  =  100% 

(HSI) 

24-48  hours  of 

information 

(HSI) 

Range  >=  30  Nm 

Plug  &  Play 

Probability  =90 
95% 

Portable 

Access  <10s 

Expandable 

Sort  <10s 

Supportable 

Maintainable 

Reliable 

Search  <  10s 

Table  F-l.  This  table  represents  the  initial  set  of  alternatives  that  were  considered.  The  list  was  the  result  of  research,  brainstorming 
and  brain  writing  techniques. 
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Table  F-2.  Preliminary  List  of  xCMA  System  Alternatives 


System  Options 

System 

Name 

COMMS 

Host  System 

Host  to 
COMMS 
Interface 

PLI 

Display 

Identify 

User  Interfaces 

Storage 

Deployability 

1 

INMARSAT 

(L-Band) 

Personal 

Digital 

Assistant 

(PDA) 

Tactical 

Internal 

Router 

DGPS 

Internal 

Color 

NIC  Card 

Keyboard,  mouse, 
and  smart  card  reader 

Internal 

Man 

2 

INMARSAT 

(L-Band) 

Laptop 

Tactical 

External 

Router 

DGPS 

External 

Monochrome 

IP  Based 

Touchscreen, 
headset,  and  camera 

External 

New  Technology 

3 

INMARSAT 

(L-Band) 

Desktop 

Commercial 

Internal 

Router 

GPS  Extrnal 

LCD 

Other 

Hardware 

Keyboard,  trackball, 
and  bio-recognition 

Remote 

Helo 

4 

INMARSAT 

(L-Band) 

PC  Based 

Commercial 

External 

Router 

GPS  Internal 

PLASMA 

New 

Technology 

Voice  recognition, 
mic  and  speakers 

Removable 

Man/ship 

5 

INMARSAT 

(L-Band) 

Rack  Mounted 
SBCs 

Tactical 

Internal 

Modem 

New 

Technology 

CRT 

IP  Based 

Voice  recognition, 
and  headset 

None 

Man/Helo 

6 

INMARSAT 

(L-Band) 

Mobile 

Terminal 

Equipment 

Tactical 

External 

Modem 

GPS  Extrnal 

Multiple 

Displays 

Other 

Hardware 

Keyboard,  mouse, 
and  bio-recognition 

Internal 

Ship 

7 

INMARSAT 

(L-Band) 

None 

Commercial 

Internal 

Modem 

DGPS 

External 

None 

None 

Touchscreen, 
headset,  and  bio¬ 
recognition 

Removable 

Helo 

8 

INMARSAT 

(L-Band) 

New 

Technology 

Commercial 

External 

Modem 

None 

New 

Technology 

NIC  Card 

Keyboard,  trackball, 
and  smart  cad  reader 

New  Technology 

None 
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System  Options 

System 

Name 

COMMS 

Host  System 

Host  to 
COMMS 
Interface 

PLI 

Display 

Identify 

User  Interfaces 

Storage 

Deployability 

9 

KU  Band 
SATCOM 

PDA 

Tactical 

Internal 

Router 

DGPS 

Internal 

Color 

NIC  Card 

Keyboard,  mouse, 
and  smart  card  reader 

Internal 

Man 

10 

KU  Band 
SATCOM 

Laptop 

Tactical 

External 

Router 

DGPS 

External 

Monochrome 

IP  Based 

Touchscreen, 
headset,  and  camera 

External 

New  Technology 

11 

KU  Band 
SATCOM 

Desktop 

Commercial 

Internal 

Router 

GPS  Extrnal 

LCD 

Other 

Hardware 

Keyboard,  trackball, 
and  bio-recognition 

Remote 

Helo 

12 

KU  Band 
SATCOM 

PC  Based 

Commercial 

External 

Router 

GPS  Internal 

PLASMA 

New 

Technology 

Voice  recognition, 
mic  and  speakers 

Removable 

Man/ship 

13 

KU  Band 
SATCOM 

Rack  Mounted 
SBCs 

Tactical 

Internal 

Modem 

New 

Technology 

CRT 

IP  Based 

Voice  recognition, 
and  headset 

None 

Man/Helo 

14 

KU  Band 
SATCOM 

Mobile 

Terminal 

Equipment 

Tactical 

External 

Modem 

GPS  Extrnal 

Multiple 

Displays 

Other 

Hardware 

Keyboard,  mouse, 
and  bio-recognition 

Internal 

Ship 

15 

KU  Band 
SATCOM 

None 

Commercial 

Internal 

Modem 

DGPS 

External 

None 

None 

Touchscreen, 
headset,  and  bio¬ 
recognition 

Removable 

Helo 

16 

KU  Band 
SATCOM 

New 

Technology 

Commercial 

External 

Modem 

None 

New 

Technology 

NIC  Card 

Keyboard,  trackball, 
and  smart  cad  reader 

New  Technology 

None 
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System  Options 

System 

Name 

COMMS 

Host  System 

Host  to 
COMMS 
Interface 

PLI 

Display 

Identify 

User  Interfaces 

Storage 

Deployability 

17 

UHF 

SATCOM 

PDA 

Tactical 

Internal 

Router 

DGPS 

Internal 

Color 

NIC  Card 

Keyboard,  mouse, 
and  smart  card  reader 

Internal 

Man 

18 

UHF 

SATCOM 

Laptop 

Tactical 

External 

Router 

DGPS 

External 

Monochrome 

IP  Based 

Touchscreen, 
headset,  and  camera 

External 

New  Technology 

19 

UHF 

SATCOM 

Desktop 

Commercial 

Internal 

Router 

GPS  Extrnal 

LCD 

Other 

Hardware 

Keyboard,  trackball, 
and  bio-recognition 

Remote 

Helo 

20 

UHF 

SATCOM 

PC  Based 

Commercial 

External 

Router 

GPS  Internal 

PLASMA 

New 

Technology 

Voice  recognition, 
mic  and  speakers 

Removable 

Man/ship 

21 

UHF 

SATCOM 

Rack  Mounted 
SBCs 

Tactical 

Internal 

Modem 

New 

Technology 

CRT 

IP  Based 

Voice  recognition, 
and  headset 

None 

Man/Helo 

22 

UHF 

SATCOM 

Mobile 

Terminal 

Equipment 

Tactical 

External 

Modem 

GPS  Extrnal 

Multiple 

Displays 

Other 

Hardware 

Keyboard,  mouse, 
and  bio-recognition 

Internal 

Ship 

23 

UHF 

SATCOM 

None 

Commercial 

Internal 

Modem 

DGPS 

External 

None 

None 

Touchscreen, 
headset,  and  bio¬ 
recognition 

Removable 

Helo 

24 

UHF 

SATCOM 

New 

Technology 

Commercial 

External 

Modem 

None 

New 

Technology 

NIC  Card 

Keyboard,  trackball, 
and  smart  cad  reader 

New  Technology 

None 
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System  Options 

System 

Name 

COMMS 

Host  System 

Host  to 
COMMS 
Interface 

PLI 

Display 

Identify 

User  Interfaces 

Storage 

Deployability 

25 

HF-LOS 

PDA 

Tactical 

Internal 

Router 

DGPS 

Internal 

Color 

NIC  Card 

Keyboard,  mouse, 
and  smart  card  reader 

Internal 

Man 

26 

HF-LOS 

Laptop 

Tactical 

External 

Router 

DGPS 

External 

Monochrome 

IP  Based 

Touchscreen, 
headset,  and  camera 

External 

New  Technology 

27 

HF-LOS 

Desktop 

Commercial 

Internal 

Router 

GPS  Extrnal 

LCD 

Other 

Hardware 

Keyboard,  trackball, 
and  bio-recognition 

Remote 

Helo 

28 

HF-LOS 

PC  Based 

Commercial 

External 

Router 

GPS  Internal 

PLASMA 

New 

Technology 

Voice  recognition, 
mic  and  speakers 

Removable 

Man/ship 

29 

HF-LOS 

Rack  Mounted 
SBCs 

Tactical 

Internal 

Modem 

New 

Technology 

CRT 

IP  Based 

Voice  recognition, 
and  headset 

None 

Man/Helo 

30 

HF-LOS 

Mobile 

Terminal 

Equipment 

Tactical 

External 

Modem 

GPS  Extrnal 

Multiple 

Displays 

Other 

Hardware 

Keyboard,  mouse, 
and  bio-recognition 

Internal 

Ship 

31 

HF-LOS 

None 

Commercial 

Internal 

Modem 

DGPS 

External 

None 

None 

Touchscreen, 
headset,  and  bio¬ 
recognition 

Removable 

Helo 

32 

HF-LOS 

New 

Technology 

Commercial 

External 

Modem 

None 

New 

Technology 

NIC  Card 

Keyboard,  trackball, 
and  smart  cad  reader 

New  Technology 

None 
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System  Options 

System 

Name 

COMMS 

Host  System 

Host  to 
COMMS 
Interface 

PLI 

Display 

Identify 

User  Interfaces 

Storage 

Deployability 

33 

UHF-LOS 

PDA 

Tactical 

Internal 

Router 

DGPS 

Internal 

Color 

NIC  Card 

Keyboard,  mouse, 
and  smart  card  reader 

Internal 

Man 

34 

UHF-LOS 

Laptop 

Tactical 

External 

Router 

DGPS 

External 

Monochrome 

IP  Based 

Touchscreen, 
headset,  and  camera 

External 

New  Technology 

35 

UHF-LOS 

Desktop 

Commercial 

Internal 

Router 

GPS  Extrnal 

LCD 

Other 

Hardware 

Keyboard,  trackball, 
and  bio-recognition 

Remote 

Helo 

36 

UHF-LOS 

PC  Based 

Commercial 

External 

Router 

GPS  Internal 

PLASMA 

New 

Technology 

Voice  recognition, 
mic  and  speakers 

Removable 

Man/ship 

37 

UHF-LOS 

Rack  Mounted 
SBCs 

Tactical 

Internal 

Modem 

New 

Technology 

CRT 

IP  Based 

Voice  recognition, 
and  headset 

None 

Man/Helo 

38 

UHF-LOS 

Mobile 

Terminal 

Equipment 

Tactical 

External 

Modem 

GPS  Extrnal 

Multiple 

Displays 

Other 

Hardware 

Keyboard,  mouse, 
and  bio-recognition 

Internal 

Ship 

39 

UHF-LOS 

None 

Commercial 

Internal 

Modem 

DGPS 

External 

None 

None 

Touchscreen, 
headset,  and  bio¬ 
recognition 

Removable 

Helo 

40 

UHF-LOS 

New 

Technology 

Commercial 

External 

Modem 

None 

New 

Technology 

NIC  Card 

Keyboard,  trackball, 
and  smart  cad  reader 

New  Technology 

None 
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System  Options 

System 

Name 

COMMS 

Host  System 

Host  to 
COMMS 
Interface 

PLI 

Display 

Identify 

User  Interfaces 

Storage 

Deployability 

41 

VHF-LOS 

PDA 

Tactical 

Internal 

Router 

DGPS 

Internal 

Color 

NIC  Card 

Keyboard,  mouse, 
and  smart  card  reader 

Internal 

Man 

42 

VHF-LOS 

Laptop 

Tactical 

External 

Router 

DGPS 

External 

Monochrome 

IP  Based 

Touchscreen, 
headset,  and  camera 

External 

New  Technology 

43 

VHF-LOS 

Desktop 

Commercial 

Internal 

Router 

GPS 

External 

LCD 

Other 

Hardware 

Keyboard,  trackball, 
and  bio-recognition 

Remote 

Helo 

44 

VHF-LOS 

PC  Based 

Commercial 

External 

Router 

GPS  Internal 

PLASMA 

New 

Technology 

Voice  recognition, 
mic  and  speakers 

Removable 

Man/ship 

45 

VHF-LOS 

Rack  Mounted 
SBCs 

Tactical 

Internal 

Modem 

New 

Technology 

CRT 

IP  Based 

Voice  recognition, 
and  headset 

None 

Man/Helo 

46 

VHF-LOS 

Mobile 

Terminal 

Equipment 

Tactical 

External 

Modem 

GPS 

External 

Multiple 

Displays 

Other 

Hardware 

Keyboard,  mouse, 
and  bio-recognition 

Internal 

Ship 

47 

VHF-LOS 

None 

Commercial 

Internal 

Modem 

DGPS 

External 

None 

None 

Touchscreen, 
headset,  and  bio¬ 
recognition 

Removable 

Helo 

48 

VHF-LOS 

New 

Technology 

Commercial 

External 

Modem 

None 

New 

Technology 

NIC  Card 

Keyboard,  trackball, 
and  smart  cad  reader 

New  Technology 

None 
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System  Options 

System 

Name 

COMMS 

Host  System 

Host  to 
COMMS 
Interface 

PLI 

Display 

Identify 

User  Interfaces 

Storage 

Deployability 

49 

Wireless 

(802.11/802.16 

) 

PDA 

Tactical 

Internal 

Router 

DGPS 

Internal 

Color 

NIC  Card 

Keyboard,  mouse, 
and  smart  card  reader 

Internal 

Man 

50 

Wireless 

(802.11/802.16 

) 

Laptop 

Tactical 

External 

Router 

DGPS 

External 

Monochrome 

IP  Based 

Touchscreen, 
headset,  and  camera 

External 

New  Technology 

51 

Wireless 

(802.11/802.16 

) 

Desktop 

Commercial 

Internal 

Router 

GPS 

External 

LCD 

Other 

Hardware 

Keyboard,  trackball, 
and  bio-recognition 

Remote 

Helo 

52 

Wireless 

(802.11/802.16 

) 

PC  Based 

Commercial 

External 

Router 

GPS  Internal 

PLASMA 

New 

Technology 

Voice  recognition, 
mic  and  speakers 

Removable 

Man/ship 

53 

Wireless 

(802.11/802.16 

) 

Rack  Mounted 
SBCs 

Tactical 

Internal 

Modem 

New 

Technology 

CRT 

IP  Based 

Voice  recognition, 
and  headset 

None 

Man/Helo 

54 

Wireless 

(802.11/802.16 

) 

Mobile 

Terminal 

Equipment 

Tactical 

External 

Modem 

GPS 

External 

Multiple 

Displays 

Other 

Hardware 

Keyboard,  mouse, 
and  bio-recognition 

Internal 

Ship 

55 

Wireless 

(802.11/802.16 

) 

None 

Commercial 

Internal 

Modem 

DGPS 

External 

None 

None 

Touchscreen, 
headset,  and  bio¬ 
recognition 

Removable 

Helo 

56 

Wireless 

(802.11/802.16 

) 

New 

Technology 

Commercial 

External 

Modem 

None 

New 

Technology 

NIC  Card 

Keyboard,  trackball, 
and  smart  cad  reader 

New  Technology 

None 
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System  Options 

System 

Name 

COMMS 

Host  System 

Host  to 
COMMS 
Interface 

PLI 

Display 

Identify 

User  Interfaces 

Storage 

Deployability 

57 

Transformatio 
nal  SATCOM 

PDA 

Tactical 

Internal 

Router 

DGPS 

Internal 

Color 

NIC  Card 

Keyboard,  mouse, 
and  smart  card  reader 

Internal 

Man 

58 

Transformatio 
nal  SATCOM 

Laptop 

Tactical 

External 

Router 

DGPS 

External 

Monochrome 

IP  Based 

Touchscreen, 
headset,  and  camera 

External 

New  Technology 

59 

Transformatio 
nal  SATCOM 

Desktop 

Commercial 

Internal 

Router 

GPS 

External 

LCD 

Other 

Hardware 

Keyboard,  trackball, 
and  bio-recognition 

Remote 

Helo 

60 

Transformatio 
nal  SATCOM 

PC  Based 

Commercial 

External 

Router 

GPS  Internal 

PLASMA 

New 

Technology 

Voice  recognition, 
mic  and  speakers 

Removable 

Man/ship 

61 

Transformatio 
nal  SATCOM 

Rack  Mounted 
SBCs 

Tactical 

Internal 

Modem 

New 

Technology 

CRT 

IP  Based 

Voice  recognition, 
and  headset 

None 

Man/Helo 

62 

Transformatio 
nal  SATCOM 

Mobile 

Terminal 

Equipment 

Tactical 

External 

Modem 

GPS 

External 

Multiple 

Displays 

Other 

Hardware 

Keyboard,  mouse, 
and  bio-recognition 

Internal 

Ship 

63 

Transformatio 
nal  SATCOM 

None 

Commercial 

Internal 

Modem 

DGPS 

External 

None 

None 

Touchscreen, 
headset,  and  bio¬ 
recognition 

Removable 

Helo 

64 

Transformatio 
nal  SATCOM 

New 

Technology 

Commercial 

External 

Modem 

None 

New 

Technology 

NIC  Card 

Keyboard,  trackball, 
and  smart  cad  reader 

New  Technology 

None 
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System  Options 

System 

Name 

COMMS 

Host  System 

Host  to 
COMMS 
Interface 

PLI 

Display 

Identify 

User  Interfaces 

Storage 

Deployability 

65 

Software 

Definable 

Radios 

PDA 

Tactical 

Internal 

Router 

DGPS 

Internal 

Color 

NIC  Card 

Keyboard,  mouse, 
and  smart  card  reader 

Internal 

Man 

66 

Software 

Definable 

Radios 

Laptop 

Tactical 

External 

Router 

DGPS 

External 

Monochrome 

IP  Based 

Touchscreen, 
headset,  and  camera 

External 

New  Technology 

67 

Software 

Definable 

Radios 

Desktop 

Commercial 

Internal 

Router 

GPS 

External 

LCD 

Other 

Hardware 

Keyboard,  trackball, 
and  bio-recognition 

Remote 

Helo 

68 

Software 

Definable 

Radios 

PC  Based 

Commercial 

External 

Router 

GPS  Internal 

PLASMA 

New 

Technology 

Voice  recognition, 
mic  and  speakers 

Removable 

Man/ship 

69 

Software 

Definable 

Radios 

Rack  Mounted 
SBCs 

Tactical 

Internal 

Modem 

New 

Technology 

CRT 

IP  Based 

Voice  recognition, 
and  headset 

None 

Man/Helo 

70 

Software 

Definable 

Radios 

Mobile 

Terminal 

Equipment 

Tactical 

External 

Modem 

GPS 

External 

Multiple 

Displays 

Other 

Hardware 

Keyboard,  mouse, 
and  bio-recognition 

Internal 

Ship 

71 

Software 

Definable 

Radios 

None 

Commercial 

Internal 

Modem 

DGPS 

External 

None 

None 

Touchscreen, 
headset,  and  bio¬ 
recognition 

Removable 

Helo 

72 

Software 

Definable 

Radios 

New 

Technology 

Commercial 

External 

Modem 

None 

New 

Technology 

NIC  Card 

Keyboard,  trackball, 
and  smart  cad  reader 

New  Technology 

None 

Table  F-2.  This  table  represents  the  alternatives  that  were  generated  as  a  result  of  the  initial  set  of  options  as  shown  in  Table  F-l. 
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Assumptions  used  to  generate  the  initial  list  of  alternatives  are: 

Commercial  Satellite  Communications  will  use  Commercial  router/modem 
Military  Satellite  Communications  will  use  Tactical  router/modem; 

Wireless  will  use  a  commercial  router/modem 

TSAT  is  a  transformational  satellite 

Web  based  network  Protocols  are  implemented 

Further  research  showed  that  IEEE  802.11  as  well  as  all  the  LOS  options  do  not 
meet  the  30  nautical  mile  range  requirement  and  are  deleted  from  the  alternatives  [Javvin 
Network  Management  and  Security,  2007]. 

Research  further  showed  that  INMARSAT  does  not  handle  the  streaming  video 
requirements.  New  technology  will  be  discussed  for  future  options,  but  will  not  be 
evaluated  due  to  the  lack  of  system  specifications  available  for  evaluation.  Upon 
defining  MTE  it  is  determined  that  MTE  is  another  form  of  a  SBC.  These  two  categories 
are  combined. 

Keeping  the  above  assumptions  in  mind  and  considering  the  restrictions  found 
through  research  for  other  protocols  and  tactical  equipment,  an  updated  list  of  options 
was  generated.  The  updated  list  of  options  is  shown  in  Table  F-3.  From  this  list  an 
updated  list  of  alternatives  was  generated  and  is  shown  in  Table  F-4. 
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Table  F-3.  Updated  List  of  xCMA  System  Options 


COMMS 

Host  System 

Router/Modem 

Software  & 
Services 

PLI 

Display 

Identify 

SATCOM-  Commercial 

Laptop 

Commercial 

DII  COE 

GPS 

LCD 

MAC  /  IP  Address 

Wireless  (802.16  or  equiv) 

Specific 

Application 

S/W 

SATCOM  - 
Military  /Government 

New  Technology 

Tactical 

CMA 

Toolset 

New  Technology 

Other  Hardware  / 
New  Technology 

Software  Definable 
Radios 

SBC 

Web  based 
Common 
Operational 
Picture 

Evaluation  Criteria 

Bandwidth 

Scalable 

Properly  interfaces 
between  Host  & 
COMMS 

N/A 

Accuracy  =  +/- 
10  meters 

(HSI) 

Accuracy  =  100% 

Range  >=30  Nm 

Plug  &  Play 

Portable 

Expandable 

Supportable 

Maintainable 

Reliable 

Table  F-3.  This  table  represents  the  revised  list  of  options  that  were  generated  as  a  result  of  the  documented  assumptions  and 
restrictions  identified  in  research. 
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Table  F-4.  Updated  List  of  Alternatives 


COMMS 

Host  System 

Router/Modem 

PLI 

Display 

Identify 

SATCOM  -  Commercial 

Laptop 

Commercial 

GPS 

LCD 

MAC/IP 

SATCOM  -  Commercial 

New  Technology 

Commercial 

GPS 

New  Technology 

Other  HW,  new  tech 

SATCOM  -  Commercial 

SBC 

Commercial 

GPS 

LCD 

MAC/IP 

SATCOM  -  Commercial 

Mobile  Terminal  Equipment 

Commercial 

GPS 

LCD 

Other  HW,  New  Tech 

SATCOM  -  Military/Govemment 

Laptop 

Tactical 

GPS 

LCD 

MAC/IP 

SATCOM  -  Military/Govemment 

New  Technology 

Tactical 

GPS 

New  Technology 

Other  HW,  new  tech 

SATCOM  -  Military/Govemment 

SBC 

Tactical 

GPS 

LCD 

MAC/IP 

SATCOM  -  Military/Govemment 

Mobile  Terminal  Equipment 

Tactical 

GPS 

LCD 

Other  HW,  New  Tech 

Wireless  802.16 

Laptop 

Commercial 

GPS 

LCD 

MAC/IP 

Wireless  802.16 

New  Technology 

Commercial 

GPS 

New  Technology 

Other  HW,  new  tech 

Wireless  802.16 

SBC 

Commercial 

GPS 

LCD 

MAC/IP 

Wireless  802.16 

Mobile  Terminal  Equipment 

Commercial 

GPS 

LCD 

Other  HW,  New  Tech 

Software  Defined  Radio 

Laptop 

Commercial 

GPS 

LCD 

MAC/IP 

Software  Defined  Radio 

New  Technology 

Commercial 

GPS 

New  Technology 

Other  HW,  new  tech 

Software  Defined  Radio 

SBC 

Commercial 

GPS 

LCD 

MAC/IP 

Software  Defined  Radio 

Mobile  Terminal  Equipment 

Commercial 

GPS 

LCD 

Other  HW,  New  Tech 

This  table  represents  the  revised  list  of  alternatives  that  were  generated  as  a  result  of  the  revised  options  as  shown  in  Table  F-3. 
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With  the  intent  to  provide  foreign  allies  and  merchant  vessels  the  xCMA  system, 
and  understanding  that  restrictions  exist  in  the  use  of  tactical  equipment,  all  tactical 
equipment  was  eliminated  from  the  list  of  alternatives.  SDRs  are  network  agnostic,  thus 
the  implementation  and  use  of  SDRs  require  an  communications  system,  i.e.  802.16m 
wireless  or  SATCOM.  Given  this  restriction,  SDRs  were  eliminated  from  the  list  of 
alternatives. 

Zwicky’s  Morphological  Box 

The  development  of  alternatives  identified  four  primary  alternatives  and  a  non 
materiel  solution.  These  options  are  used  to  determine  the  system  designs  by  selecting 
different  tracks.  They  are  listed  below  and  graphically  in  Table  G-5  known  as  Zwicky’s 
Morphological  Box. 

•  Non  Materiel  -  Change  CONOPS;  use  the  existing  networks  and  infrastructure. 
Modify  mission  responsibilities  and  operational  concepts. 

•  Develop  a  SATCOM-Laptop  system  using  existing  commercial  SATCOM  with  a 
COTS  laptop. 

•  Develop  a  SATCOM-SBC  system  using  existing  commercial  SATCOM  with  a 
SBC  MTE. 

•  Develop  a  Wireless-Laptop  system  using  802. 16m  wireless  protocols  with  a 
COTS  laptop. 

•  Develop  a  Wireless  -SBC  system  using  802. 16m  wireless  protocols  with  a  SBC 
MTE. 
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Table  F-5.  Zwicky’s  Mophological  Box  of  possible  xCMA  system  alternatives. 


Table  F-5  identifies  four  primary  alternatives  and  a  non  materiel  solution.  These  options 
were  used  to  detennine  the  system  designs.  This  representation  of  system  alternatives  is 
a  systems  engineering  tool  known  as  Zwicky’s  Morphological  Box. 


This  colorfully  illustrates  the  creation  of  each  xCMA  system  candidate.  Different 
system  attributes  are  selected  from  left  to  right  under  the  System  Functions  title  box. 
Mixing  and  matching  the  different  attributes  generates  combinations  of  options  for  each 
alternative. 

The  non-materiel  solution  uses  the  existing  networks  and  infrastructure. 
Modification  of  mission  responsibilities,  operational  concepts  and  technologies  would  not 
provide  adequate  CMA  connectivity  to  the  disconnected  vessel  or  user.  Limited 
connectivity  could  be  provided  on  an  adhoc  basis  using  existing  UHF/VHF  radio 
telephones  and  possibly  messenger  services  (small  boat  and  helicopter  delivery  of  maps, 
orders).  This  does  not  provide  the  capability  for  Node  5  to  effectively  and  efficiently 
communicate  with  the  humanitarian  operation  vessels  using  streaming  video,  text, 
pictures,  e-mail,  and  chat.  Since  this  solution  does  not  meet  the  requirement  it  is 
eliminated  from  the  list  of  alternatives.  The  final  list  of  alternatives  is  shown  in  Table  F- 
6. 
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Table  F-6.  Final  List  of  xCMA  system  alternatives 


Alternatives 

COMMS 

Host  System 

Router/Modem 

PLI 

Display 

Identify 

1.  SATCOM- 
Laptop 

SATCOM  -  Commercial 

Laptop 

Commercial 

GPS 

LCD 

MAC/IP 

2.  SATCOM- 
SBC 

SATCOM  -  Commercial 

Integrated  SBC  (MTE) 

Commercial 

GPS 

LCD 

MAC/IP 

3.  Wireless- 
Laptop 

Wireless  802.16 

Laptop 

Commercial 

GPS 

LCD 

MAC/IP 

4.  Wireless- 
SBC 

Wireless  802.16 

Integrated  SBC  (MTE) 

Commercial 

GPS 

LCD 

MAC/IP 

Table  F-6  provides  the  final  list  of  alternatives  generated. 
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APPENDIX  G.  RELIABILITY  MODELING 


The  QFD  results  show  reliability  to  be  of  major  concern  in  the  selection  of  the 
xCMA  system.  Since  reliability  has  a  very  high  rating  factor,  modeling  and  simulation  is 
applied  to  determine  the  reliability  of  each  of  the  four  proposed  alternatives. 

A  mathematical  model  was  constructed  using  Microsoft  Excel.  To  properly 
calculate  a  95%  confidence  interval  and  reduce  errors  in  the  simulation  process,  the 
model  is  constructed  using  300  replications. 

Table  G-l  detailed  the  source  of  MTBF  values  used  in  the  simulation.  As  part  of 
the  reliability  simulation  actual  values  for  MTBF  are  used  on  existing  systems.  A 
simulation  summary  is  given  for  each  of  the  alternatives  in  Tables  G-2  through  G-5. 
Table  G-2  shows  the  detailed  summary  for  Alternative  1  —  SATCOM-Laptop.  Table  G-3 
shows  the  detailed  summary  for  Alternative  2  —  SATCOM-SBC.  Table  G-4  shows  the 
detailed  summary  for  Alternative  3  —  Wireless-Laptop.  Table  G-5  shows  the  detailed 
summary  for  Alternative  4  —  Wireless-SBC.  The  xCMA  system  reliability  for  each 
alternative  is  shown  in  Table  G-6. 
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Table  G-l.  Manufacturers’  published  MTBF  values  and  Calculated  Reliabilities 


Option 

Component 

MTBF 

Avgerage 

MTBF 

-1/MTBF 

Reliability 
for  ~14 

davs 

1 

Communications:  SATCOM-Commercial 

2,200 

16,206 

8,760 

9,055 

(0.000110432) 

0.96 

Host  System:  Laptop 

10,000 

10,000 

(0.000100000) 

0.97 

Router/Modem:  Commercial 

1,556,100 

1,123,223 

586,683 

706,709 

300,000 

342,000 

316,000 

350,000 

660,089 

(0.000001515) 

1.00 

Display:  LCD 

20,000 

25,000 

22,500 

(0.000044444) 

0.99 

Identify:  MAC/IP 

139,416 

139,416 

(0.000007173) 

1.00 

Communications:  SATCOM-Commercial 

2,200 

16,206 

8,760 

9,055 

(0.000110432) 

0.96 

Host  System:  Single  Board  Computer  (MTE) 

144,036 

144,036 

(0.000006943) 

1.00 

2 

Router/Modem:  Commercial 

1,556,100 

1,123,223 

586,683 

706,709 

300,000 

342,000 

316,000 

350,000 

660,089 

(0.000001515) 

1.00 

Display:  LCD 

20,000 

25,000 

22,500 

(0.000044444) 

0.98 

Identify:  MAC/IP 

139,416 

139,416 

(0.000007173) 

1.00 

Communications:  Wireless  802.16 

183,000 

100,000 

141,500 

(0.000007067) 

1.00 

Host  System:  Laptop 

10,000 

10,000 

(0.000100000) 

0.97 

3 

Router/Modem:  Commercial 

1,556,100 

1,123,223 

586,683 

706,709 

300,000 

342,000 

316,000 

350,000 

660,089 

(0.000001515) 

1.00 

Display:  LCD 

20,000 

25,000 

22,500 

(0.000044444) 

0.99 

Identify:  MAC/IP 

139,416 

139,416 

(0.000007173) 

1.00 

Communications:  Wireless  802.16 

183,000 

100,000 

141,500 

(0.000007067) 

1.00 

Host  System:  Single  Board  Computer  (MTE) 

144,036 

144,036 

(0.000006943) 

1.00 

4 

Router/Modem:  Commercial 

1,556,100 

1,123,223 

586,683 

706,709 

300,000 

342,000 

316,000 

350,000 

660,089 

(0.000001515) 

1.00 

Display:  LCD 

20,000 

25,000 

22,500 

(0.000044444) 

0.99 

Identify:  MAC/IP 

139,416 

139,416 

(0.000007173) 

1.00 

Table  G-l  provides  a  summary  of  manufacturers’  published  MTBF  values  obtained  from  research  of  similar  systems.  The  MTBF 
values  for  each  component  are  averaged  and  used  to  calculate  the  component  reliability. 
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Table  G-2.  Reliability  Simulation  for  xCMA  System  Alternative  1:  SATCOM-Laptop 

Summary  Replications 


Components 

Communications: 

SATCOM- 

Commercial 

Host  System: 
Laptop 

Router/Modem: 

Commercial 

Display:  LCD 

Identify:  MAC/IP 

1  Replication 

Avgerage  MTBF 

9,055 

10,000 

660,089 

22,500 

139,416 

-1/MTBF 

-0.000110 

-0.000100 

-0.000002 

-0.000044 

-0.000007 

Reliability  for  -14  days 

96.35% 

96.69% 

99.95% 

98.55% 

99.76% 

|System  /  Component  Survive?  [  Yes  |  Yes  |  Yes  |  Yes  |  Yes 


i  Yes  i 


300 

Replications 

Num  of  Replications 

300 

300 

300 

300 

300 

Average  Reliability 

96.36% 

96.69% 

99.95% 

98.52% 

99.76% 

SD  of  Reliability 

0.04% 

0.04% 

0.00% 

0.02% 

0.00% 

Conf  Level 

95% 

95% 

95% 

95% 

95% 

Alpha 

5% 

5% 

5% 

5% 

5% 

Conf  Width  of  Reliability 

0.0048% 

0.0041% 

0.0001% 

0.0021% 

0.0003% 

Cl  Low  of  Average  Reliability 

96.35% 

96.69% 

99.95% 

98.52% 

99.76% 

Cl  High  of  Average  Reliability 

96.36% 

96.70% 

99.95% 

98.52% 

99.76% 

|System  /  Component  Survive?  |  Yes  |  Yes  |  Yes  |  Yes  |  Yes  ~~J  |  Yes' 


Components 


Communications: 

SATCOM- 

Commercial 

Host  System: 
Laptop 

Router/Modem: 

Commercial 

Display:  LCD 

Identify:  MAC/IP 

1 

96.35% 

96.69% 

99.95% 

98.55% 

99.76% 

2 

96.40% 

96.67% 

99.95% 

98.48% 

99.76% 

3 

96.36% 

96.70% 

99.95% 

98.54% 

99.76% 

4 

96.32% 

96.71% 

99.95% 

98.51% 

99.76% 

5 

96.40% 

96.67% 

99.95% 

98.51% 

99.76% 

6 

96.30% 

96.65% 

99.95% 

98.53% 

99.76% 

7 

96.38% 

96.65% 

99.95% 

98.50% 

99.76% 

8 

96.28% 

96.68% 

99.95% 

98.49% 

99.76% 

9 

96.34% 

96.76% 

99.95% 

98.52% 

99.76% 

10 

96.37% 

96.73% 

99.95% 

98.55% 

99.76% 

11 

96.35% 

96.71% 

99.95% 

98.52% 

99.76% 

12 

96.38% 

96.69% 

99.95% 

98.50% 

99.76% 

13 

96.34% 

96.69% 

99.95% 

98.50% 

99.76% 

|S2|4 

96.44% 

96.71% 

99.95% 

98.53% 

99.76% 

15 

96.32% 

96.66% 

99.95% 

98.51% 

99.76% 

16 

96.39% 

96.73% 

99.95% 

98.49% 

99.76% 

17 

96.39% 

96.70% 

99.95% 

98.51% 

99.76% 

B8 

96.37% 

96.72% 

99.95% 

98.51% 

99.76% 

19 

96.32% 

96.71% 

99.95% 

98.54% 

99.76% 

20 

96.25% 

96.74% 

99.95% 

98.52% 

99.76% 

21 

96.37% 

96.66% 

99.95% 

98.53% 

99.76% 

22 

96.29% 

96.72% 

99.95% 

98.50% 

99.76% 

23 

96.42% 

96.66% 

99.95% 

98.51% 

99.76% 

24 

96.35% 

96.67% 

99.95% 

98.51% 

99.76% 

25 

96.37% 

96.68% 

99.95% 

98.52% 

99.77% 

26 

96.33% 

96.69% 

99.95% 

98.54% 

99.76% 

27 

96.25% 

96.72% 

99.95% 

98.51% 

99.75% 

28 

96.32% 

96.66% 

99.95% 

98.52% 

99.76% 

29 

96.35% 

96.71% 

99.95% 

98.52% 

99.76% 

30 

96.29% 

96.80% 

99.95% 

98.49% 

99.76% 

31 

96.38% 

96.62% 

99.95% 

98.52% 

99.76% 

32 

96.30% 

96.67% 

99.95% 

98.52% 

99.76% 

33 

96.31% 

96.76% 

99.95% 

98.53% 

99.75% 

34 

96.38% 

96.76% 

99.95% 

98.50% 

99.76% 

||jg35 

96.29% 

96.71% 

99.95% 

98.54% 

99.76% 

36 

96.39% 

96.76% 

99.95% 

98.55% 

99.77% 

37 

96.41% 

96.73% 

99.95% 

98.50% 

99.76% 

38 

96.42% 

96.68% 

99.95% 

98.50% 

99.76% 

39 

96.32% 

96.74% 

99.95% 

98.54% 

99.76% 

40 

96.33% 

96.69% 

99.95% 

98.53% 

99.76% 

296 

96.38% 

96.69% 

99.95% 

98.51% 

99.76% 

297 

96.36% 

96.64% 

99.95% 

98.53% 

99.76% 

298 

96.38% 

96.72% 

99.95% 

98.52% 

99.76% 

299 

96.38% 

96.69% 

99.95% 

98.50% 

99.76% 

300 

96.44% 

96.75% 

99.95% 

98.53% 

99.76% 

Table  G-2  summarizes  the  reliability  simulation  results  for  SATCOM-Laptop  combination. 
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Table  G-3.  Reliability  Simulation  for  xCMA  System  Alternative  2:  SATCOM-SBC 

Summary 


Replications 


Components 

Communications: 

SATCOM- 

Commercial 

Host  System: 
Single  Board 
Computer  (MTE) 

Router/Modem: 

Commercial 

Display:  LCD 

Identify:  MAC/IP 

1  Replication 

Avgerage  MTBF 

9,055 

144,036 

660,089 

22,500 

139,416 

-1/MTBF 

-0.000110 

-0.000007 

-0.000002 

-0.000044 

-0.000007 

Reliability  for  -14  days 

96.33% 

99.76% 

99.95% 

98.54% 

99.76% 

|System  /  Component  Survive?  |  Yes  |  Yes  |  Yes  |  Yes  |  Yes  ~~|  |  Yes' 


300 

Replications 

Num  of  Replications 

300 

300 

300 

300 

300 

Average  Reliability 

96.36% 

99.77% 

99.95% 

98.52% 

99.76% 

SD  of  Reliability 

0.04% 

0.00% 

0.00% 

0.02% 

0.00% 

Conf  Level 

95% 

95% 

95% 

95% 

95% 

Alpha 

5% 

5% 

5% 

5% 

5% 

Conf  Width  of  Reliability 

0.0048% 

0.0003% 

0.0001% 

0.0021% 

0.0003% 

Cl  Low  of  Average  Reliability 

96.35% 

99.77% 

99.95% 

98.52% 

99.76% 

Cl  High  of  Average  Reliability 

96.36% 

99.77% 

99.95% 

98.52% 

99.76% 

|System  /  Component  Survive?  |  Yes  |  Yes  |  Yes  |  Yes  |  Yes  ~~[  |  Ye~ 


Components 


Communications: 

SATCOM- 

Commercial 

Host  System: 
Laptop 

Router/Modem: 

Commercial 

Display:  LCD 

Identify:  MAC/IP 

1 

96.33% 

99.76% 

99.95% 

98.54% 

99.76% 

2 

96.40% 

99.77% 

99.95% 

98.52% 

99.76% 

3 

96.31% 

99.76% 

99.95% 

98.52% 

99.75% 

|  4 

96.41% 

99.77% 

99.95% 

98.53% 

99.76% 

5 

96.38% 

99.77% 

99.95% 

98.51% 

99.76% 

6 

96.31% 

99.77% 

99.95% 

98.51% 

99.76% 

\m  7 

96.32% 

99.77% 

99.95% 

98.53% 

99.76% 

|  8 

96.40% 

99.77% 

99.95% 

98.55% 

99.76% 

9 

96.34% 

99.77% 

99.95% 

98.51% 

99.76% 

10 

96.31% 

99.77% 

99.95% 

98.52% 

99.76% 

11 

96.38% 

99.77% 

99.95% 

98.48% 

99.76% 

|!E32 

96.38% 

99.76% 

99.95% 

98.50% 

99.76% 

13 

96.33% 

99.77% 

99.95% 

98.54% 

99.76% 

14 

96.34% 

99.76% 

99.95% 

98.52% 

99.76% 

|S£I5 

96.35% 

99.76% 

99.95% 

98.55% 

99.76% 

|[rj6 

96.30% 

99.77% 

99.95% 

98.52% 

99.76% 

|p!7 

96.30% 

99.76% 

99.95% 

98.53% 

99.76% 

18 

96.35% 

99.76% 

99.95% 

98.52% 

99.76% 

19 

96.34% 

99.77% 

99.95% 

98.57% 

99.76% 

20 

96.31% 

99.77% 

99.95% 

98.49% 

99.76% 

21 

96.31% 

99.77% 

99.95% 

98.56% 

99.76% 

22 

96.38% 

99.77% 

99.95% 

98.50% 

99.76% 

23 

96.32% 

99.77% 

99.95% 

98.55% 

99.76% 

24 

96.37% 

99.77% 

99.95% 

98.50% 

99.75% 

25 

96.39% 

99.77% 

99.95% 

98.54% 

99.76% 

26 

96.33% 

99.77% 

99.95% 

98.49% 

99.76% 

27 

96.41% 

99.77% 

99.95% 

98.53% 

99.76% 

28 

96.35% 

99.77% 

99.95% 

98.51% 

99.76% 

29 

96.38% 

99.77% 

99.95% 

98.50% 

99.76% 

30 

96.34% 

99.77% 

99.95% 

98.54% 

99.76% 

31 

96.46% 

99.76% 

99.95% 

98.54% 

99.76% 

32 

96.34% 

99.76% 

99.95% 

98.52% 

99.77% 

33 

96.30% 

99.76% 

99.95% 

98.51% 

99.76% 

■4 

96.36% 

99.77% 

99.95% 

98.51% 

99.76% 

35 

96.39% 

99.76% 

99.95% 

98.51% 

99.76% 

36 

96.41% 

99.77% 

99.95% 

98.50% 

99.75% 

37 

96.33% 

99.76% 

99.95% 

98.54% 

99.76% 

38 

96.29% 

99.77% 

99.95% 

98.53% 

99.76% 

39 

96.40% 

99.77% 

99.95% 

98.53% 

99.76% 

40 

96.39% 

99.76% 

99.95% 

98.54% 

99.76% 

296 

96.43% 

99.77% 

99.95% 

98.53% 

99.76% 

297 

96.36% 

99.77% 

99.95% 

98.53% 

99.76% 

298 

96.46% 

99.77% 

99.95% 

98.50% 

99.76% 

299 

96.34% 

99.77% 

99.95% 

98.55% 

99.76% 

300 

96.35% 

99.77% 

99.95% 

98.51% 

99.76% 

Table  G-3  summarizes  the  reliability  simulation  results  for  the  SATCOM-SBC  combination. 


G-4 


Table  G-4.  Reliability  Simulation  for  xCMA  System  Alternative  3:  Wireless-Laptop 

Summary 


Replications 


Components 

Communications: 
Wireless  802.16 

Host  System: 
Laptop 

Router/Modem: 

Commercial 

Display:  LCD 

Identify:  MAC/IP 

1  Replication 

Avgerage  MTBF 

141,500 

10,000 

660,089 

22,500 

139,416 

-1/MTBF 

-0.000007 

-0.000100 

-0.000002 

-0.000044 

-0.000007 

Reliability  for  ~14  days 

99.76% 

96.70% 

99.95% 

98.52% 

99.76% 

|System  /  Component  Survive?  |  Yes  |  Yes  |  Yes  |  Yes  |  Yes 


I  Yes  I 


300 

Replications 

Num  of  Replications 

300 

300 

300 

300 

300 

Average  Reliability 

99.76% 

96.69% 

99.95% 

98.52% 

99.76% 

SD  of  Reliability 

0.00% 

0.04% 

0.00% 

0.02% 

0.00% 

Conf  Level 

95% 

95% 

95% 

95% 

95% 

Alpha 

5% 

5% 

5% 

5% 

5% 

Conf  Width  of  Reliability 

0.0003% 

0.0045% 

0.0001% 

0.0019% 

0.0003% 

Cl  Low  of  Average  Reliability 

99.76% 

96.69% 

99.95% 

98.51% 

99.76% 

Cl  High  of  Average  Reliability 

99.76% 

96.70% 

99.95% 

98.52% 

99.76% 

|System  /  Component  Survive?  |  Yes  |  Yes  |  Yes  |  Yes  |  Yes  ~|  |  Ye~ 


Components 


Communications: 

SATCOM- 

Commercial 

Host  System: 
Laptop 

Router/Modem: 

Commercial 

Display:  LCD 

Identify:  MAC/IP 

1 

99.76% 

96.70% 

99.95% 

98.52% 

99.76% 

2 

99.76% 

96.78% 

99.95% 

98.53% 

99.76% 

3 

99.76% 

96.65% 

99.95% 

98.55% 

99.75% 

\Wi4 

99.77% 

96.74% 

99.95% 

98.50% 

99.76% 

5 

99.76% 

96.71% 

99.95% 

98.51% 

99.76% 

6 

99.77% 

96.69% 

99.95% 

98.51% 

99.76% 

||Sj 7 

99.76% 

96.71% 

99.95% 

98.50% 

99.76% 

|:  8 

99.76% 

96.74% 

99.95% 

98.51% 

99.76% 

9 

99.76% 

96.68% 

99.95% 

98.53% 

99.76% 

10 

99.76% 

96.77% 

99.95% 

98.50% 

99.76% 

11 

99.76% 

96.61% 

99.95% 

98.52% 

99.76% 

10^)2 

99.77% 

96.66% 

99.95% 

98.54% 

99.75% 

13 

99.76% 

96.70% 

99.95% 

98.50% 

99.76% 

14 

99.76% 

96.73% 

99.95% 

98.52% 

99.76% 

15 

99.77% 

96.69% 

99.95% 

98.54% 

99.76% 

\06 

99.76% 

96.69% 

99.95% 

98.53% 

99.76% 

17 

99.76% 

96.65% 

99.95% 

98.51% 

99.77% 

18 

99.76% 

96.70% 

99.95% 

98.53% 

99.76% 

19 

99.76% 

96.67% 

99.95% 

98.53% 

99.76% 

20 

99.76% 

96.69% 

99.95% 

98.52% 

99.76% 

21 

99.76% 

96.69% 

99.95% 

98.53% 

99.76% 

22 

99.76% 

96.66% 

99.95% 

98.52% 

99.76% 

23 

99.76% 

96.72% 

99.95% 

98.51% 

99.76% 

24 

99.77% 

96.72% 

99.95% 

98.53% 

99.76% 

25 

99.76% 

96.69% 

99.95% 

98.49% 

99.76% 

26 

99.76% 

96.71% 

99.95% 

98.49% 

99.76% 

27 

99.77% 

96.70% 

99.95% 

98.53% 

99.76% 

28 

99.76% 

96.67% 

99.95% 

98.53% 

99.76% 

29 

99.76% 

96.70% 

99.95% 

98.54% 

99.76% 

30 

99.77% 

96.68% 

99.95% 

98.54% 

99.76% 

31 

99.76% 

96.64% 

99.95% 

98.53% 

99.76% 

32 

99.76% 

96.78% 

99.95% 

98.52% 

99.75% 

33 

99.76% 

96.74% 

99.95% 

98.52% 

99.76% 

34 

99.77% 

96.69% 

99.95% 

98.53% 

99.76% 

35 

99.76% 

96.73% 

99.95% 

98.51% 

99.76% 

36 

99.76% 

96.64% 

99.95% 

98.51% 

99.76% 

37 

99.77% 

96.71% 

99.95% 

98.53% 

99.76% 

38 

99.76% 

96.61% 

99.95% 

98.53% 

99.76% 

39 

99.77% 

96.62% 

99.95% 

98.53% 

99.76% 

40 

99.77% 

96.73% 

99.95% 

98.56% 

99.76% 

296 

99.76% 

96.68% 

99.95% 

98.50% 

99.76% 

297 

99.77% 

96.67% 

99.95% 

98.48% 

99.76% 

298 

99.76% 

96.76% 

99.95% 

98.52% 

99.76% 

299 

99.76% 

96.72% 

99.95% 

98.50% 

99.76% 

300 

99.76% 

96.66% 

99.95% 

98.52% 

99.76% 

Table  G-4  summarizes  the  reliability  simulation  results  for  the  Wireless-Laptop  combination. 


G-5 


Table  G-5.  Reliability  Simulation  for  xCMA  System  Alternative  4:  Wireless-SBC 


Summary 


Replications 


Components 

Communications: 
Wireless  802.16 

Host  System: 
Single  Board 
Computer  (MTE) 

Router/Modem: 

Commercial 

Display:  LCD 

Identify:  MAC/IP 

1  Replication 

Avgerage  MTBF 

141,500 

144,036 

660,089 

22,500 

139,416 

-1/MTBF 

-0.000007 

-0.000007 

-0.000002 

-0.000044 

-0.000007 

Reliability  for  ~14  days 

99.77% 

99.77% 

99.95% 

98.50% 

99.76% 

|System  /  Component  Survive?  |  Yes  |  Yes  |  Yes  |  Yes  |  Yes 


I  Yes  I 


300 

Replications 

Num  of  Replications 

300 

300 

300 

300 

300 

Average  Reliability 

99.76% 

99.77% 

99.95% 

98.52% 

99.76% 

SD  of  Reliability 

0.00% 

0.00% 

0.00% 

0.02% 

0.00% 

Conf  Level 

95% 

95% 

95% 

95% 

95% 

Alpha 

5% 

5% 

5% 

5% 

5% 

Conf  Width  of  Reliability 

0.0003% 

0.0003% 

0.0001% 

0.0020% 

0.0003% 

Cl  Low  of  Average  Reliability 

99.76% 

99.77% 

99.95% 

98.52% 

99.76% 

Cl  High  of  Average  Reliability 

99.76% 

99.77% 

99.95% 

98.52% 

99.76% 

|System  /  Component  Survive?  |  Yes  |  Yes  |  Yes  |  Yes  |  Yes  ~|  |  Ye~ 


Components 


Communications: 

SATCOM- 

Commerciai 

Host  System: 
Laptop 

Router/Modem: 

Commercial 

Display:  LCD 

Identify:  MAC/IP 

1 

99.77% 

99.77% 

99.95% 

98.50% 

99.76% 

2 

99.76% 

99.77% 

99.95% 

98.54% 

99.76% 

IP3 

99.77% 

99.76% 

99.95% 

98.49% 

99.76% 

|tlS  4 

99.77% 

99.76% 

99.95% 

98.51% 

99.76% 

5 

99.76% 

99.77% 

99.95% 

98.54% 

99.76% 

6 

99.76% 

99.77% 

99.95% 

98.51% 

99.76% 

7 

99.76% 

99.77% 

99.95% 

98.56% 

99.76% 

8 

99.76% 

99.77% 

99.95% 

98.50% 

99.76% 

9 

99.76% 

99.77% 

99.95% 

98.51% 

99.76% 

10 

99.76% 

99.76% 

99.95% 

98.54% 

99.76% 

11 

99.77% 

99.77% 

99.95% 

98.50% 

99.76% 

12 

99.76% 

99.76% 

99.95% 

98.51% 

99.76% 

||$  3 

99.77% 

99.77% 

99.95% 

98.52% 

99.76% 

14 

99.76% 

99.77% 

99.95% 

98.50% 

99.76% 

15 

99.77% 

99.77% 

99.95% 

98.55% 

99.76% 

|t^6 

99.77% 

99.77% 

99.95% 

98.49% 

99.76% 

17 

99.76% 

99.77% 

99.95% 

98.53% 

99.76% 

18 

99.76% 

99.76% 

99.95% 

98.51% 

99.76% 

19 

99.76% 

99.77% 

99.95% 

98.50% 

99.76% 

20 

99.76% 

99.76% 

99.95% 

98.53% 

99.76% 

21 

99.76% 

99.76% 

99.95% 

98.52% 

99.76% 

22 

99.77% 

99.77% 

99.95% 

98.50% 

99.75% 

23 

99.76% 

99.76% 

99.95% 

98.50% 

99.76% 

24 

99.76% 

99.76% 

99.95% 

98.51% 

99.76% 

25 

99.76% 

99.77% 

99.95% 

98.50% 

99.76% 

26 

99.76% 

99.76% 

99.95% 

98.49% 

99.75% 

27 

99.76% 

99.77% 

99.95% 

98.54% 

99.76% 

i&|8 

99.76% 

99.77% 

99.95% 

98.49% 

99.76% 

29 

99.76% 

99.77% 

99.95% 

98.53% 

99.76% 

30 

99.77% 

99.77% 

99.95% 

98.48% 

99.75% 

31 

99.76% 

99.77% 

99.95% 

98.51% 

99.76% 

32 

99.76% 

99.76% 

99.95% 

98.52% 

99.76% 

33 

99.76% 

99.77% 

99.95% 

98.53% 

99.76% 

34 

99.77% 

99.77% 

99.95% 

98.53% 

99.76% 

35 

99.77% 

99.77% 

99.95% 

98.53% 

99.76% 

36 

99.76% 

99.76% 

99.95% 

98.51% 

99.76% 

37 

99.76% 

99.77% 

99.95% 

98.52% 

99.75% 

38 

99.76% 

99.77% 

99.95% 

98.53% 

99.76% 

39 

99.76% 

99.77% 

99.95% 

98.49% 

99.76% 

40 

99.76% 

99.77% 

99.95% 

98.51% 

99.76% 

296 

99.76% 

99.77% 

99.95% 

98.52% 

99.76% 

297 

99.76% 

99.77% 

99.95% 

98.52% 

99.76% 

298 

99.76% 

99.77% 

99.95% 

98.53% 

99.76% 

299 

99.77% 

99.76% 

99.95% 

98.51% 

99.77% 

300 

99.76% 

99.77% 

99.95% 

98.51% 

99.76% 

Table  G-5  summarizes  the  reliability  simulation  results  for  Wireless-SBC  combination. 


G-6 


Table  G-6.  xCMA  System  Reliability  Simulation  Results 


Option 

Component 

Avgerage 

MTBF 

-1/MTBF 

Reliability 
for  ~14 
days 

Num  of 
Replications 

Average 

Reliability 

SD  of 
Reliability 

Conf  Level 

Alpha 

Conf  Width 
of 

Reliability 

Cl  Low  of 
Average 
Reliability 

Cl  High  of 
Average 
Reliability 

Component 

Survive? 

System 

Reliability 

System 
MTBF  (hrs) 

Communications:  SATCOM-Commercial 

9,055 

(0.000110432) 

0.96 

300 

96.36% 

0.0422% 

95% 

5% 

0.0048% 

96.35% 

96.36% 

Yes 

Host  System:  Laptop 

10,000 

(0.000100000) 

0.97 

300 

96.69% 

0.0364% 

95% 

5% 

0.0041% 

96.69% 

96.70% 

Yes 

1 

Router/Modem:  Commercial 

660,089 

(0.000001515) 

1.00 

300 

99.95% 

0.0006% 

95% 

5% 

0.0001% 

99.95% 

99.95% 

Yes 

91.52% 

3,794 

Display:  LCD 

22,500 

(0.000044444) 

0.99 

300 

98.52% 

0.0182% 

95% 

5% 

0.0021% 

98.52% 

98.52% 

Yes 

Identify:  MAC/IP 

139,416 

(0.000007173) 

1.00 

300 

99.76% 

0.0027% 

95% 

5% 

0.0003% 

99.76% 

99.76% 

Yes 

Communications:  SATCOM-Commercial 

9,055 

(0.000110432) 

0.96 

300 

96.36% 

0.0420% 

95% 

5% 

0.0048% 

96.35% 

96.36% 

Yes 

Host  System:  Single  Board  Computer  (MTE) 

144,036 

(0.000006943) 

1.00 

300 

99.77% 

0.0026% 

95% 

5% 

0.0003% 

99.77% 

99.77% 

Yes 

Router/Modem:  Commercial 

660,089 

(0.000001515) 

1.00 

300 

99.95% 

0.0006% 

95% 

5% 

0.0001% 

99.95% 

99.95% 

Yes 

94.43% 

5,864 

Display:  LCD 

22,500 

(0.000044444) 

0.99 

300 

98.52% 

0.0182% 

95% 

5% 

0.0021% 

98.52% 

98.52% 

Yes 

Identify:  MAC/IP 

139,416 

(0.000007173) 

1.00 

300 

99.76% 

0.0029% 

95% 

5% 

0.0003% 

99.76% 

99.76% 

Yes 

3 

Communications:  Wireless  802.16 

141,500 

(0.000007067) 

1.00 

300 

99.76% 

0.0029% 

95% 

5% 

0.0003% 

99.76% 

99.76% 

Yes 

94.75% 

6,236 

Host  System:  Laptop 

10,000 

(0.000100000) 

0.97 

300 

96.69% 

0.0397% 

95% 

5% 

0.0045% 

96.69% 

96.70% 

Yes 

Router/Modem:  Commercial 

660,089 

(0.000001515) 

1.00 

300 

99.95% 

0.0006% 

95% 

5% 

0.0001% 

99.95% 

99.95% 

Yes 

Display:  LCD 

22,500 

(0.000044444) 

0.99 

300 

98.52% 

0.0167% 

95% 

5% 

0.0019% 

98.51% 

98.52% 

Yes 

Identify:  MAC/IP 

139,416 

(0.000007173) 

1.00 

300 

99.76% 

0.0027% 

95% 

5% 

0.0003% 

99.76% 

99.76% 

Yes 

4 

Communications:  Wireless  802.16 

141,500 

(0.000007067) 

1.00 

300 

99.76% 

0.0029% 

95% 

5% 

0.0003% 

99.76% 

99.76% 

Yes 

97.77% 

14,893 

Host  System:  Single  Board  Computer  (MTE) 

144,036 

(0.000006943) 

1.00 

300 

99.77% 

0.0029% 

95% 

5% 

0.0003% 

99.77% 

99.77% 

Yes 

Router/Modem:  Commercial 

660,089 

(0.000001515) 

1.00 

300 

99.95% 

0.0006% 

95% 

5% 

0.0001% 

99.95% 

99.95% 

Yes 

Display:  LCD 

22,500 

(0.000044444) 

0.99 

300 

98.52% 

0.0178% 

95% 

5% 

0.0020% 

98.52% 

98.52% 

Yes 

Identify:  MAC/IP 

139,416 

(0.000007173) 

1.00 

300 

99.76% 

0.0029% 

95% 

5% 

0.0003% 

99.76% 

99.76% 

Yes 

Table  G-6  provides  a  summary  of  the  xCMA  system  reliability  simulation  results.  These  results  are  based  on  300  replications  with 
95%  confidence  level. 
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APPENDIX  H.  THROUGHPUT  MODELING 


A  mathematical  model  was  constructed  using  Microsoft  Excel.  A  summary  of  the 
mathematical  model  results  for  the  SATCOM  Laptop  and  SATCOM  SBC  options  is  shown  in 
Figure  H-l.  A  summary  of  the  mathematical  model  results  for  the  Wireless  Laptop  and  Wireless 
SBC  options  is  shown  Figure  H-2.  To  properly  calculate  a  95%  confidence  interval  and  reduce 
errors  in  the  simulation  process,  the  model  is  constructed  using  30  replications  for  each  of  the 
listed  alternatives,  which  are  then  repeated  in  a  set  of  500  totaling  15,000  replications.  The 
simulation  results  for  the  SATCOM  Laptop  and  SATCOM  SBC  are  listed  in  Table  H-l. 
Simulation  results  for  the  Wireless  alternatives  are  listed  in  Table  H-2.  Immediately  following 
the  summary  are  detailed  results  for  the  500  replications. 
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M/M/s 

Arrival  rate  (Kbps) 

128 

Assumes  Poisson  process  for 

Service  rate  (Kbps) 

235 

arrivals  and  services. 

Number  of  servers 

1 

Utilization 

54.47% 

P(0),  probability  that  the  system  is  empty 

0.4553 

Lq,  expected  queue  length 

0.6516 

L,  expected  number  in  system 

1.1963 

Wq,  expected  time  in  queue 

0.00509 

W,  expected  total  time  in  system  (sec) 

0.00935 

Probability  that  data  waits  to  be  processed 

1.36% 
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NUMBER  IN  SYSTEM 

Figure  H-l.  Mathematical  model  results  for  SATCOM-Laptop  and  SATCOM-SBC  systems.  This  figure  captures  the  results  from  the 
mathematical  model  for  SATCOM-  Laptop  and  SATCOM-SBC  systems. 
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M/M/s 

Arrival  rate  (Kbps) 

128 

Assumes  Poisson  process  for 

Service  rate  (Kbps) 

3,729 

arrivals  and  services. 

Number  of  servers 

1 

Utilization 

3.43% 

P(0),  probability  that  the  system  is  empty 

0.9657 

Lq,  expected  queue  length 

0.0012 

L,  expected  number  in  system 

0.0355 

Wq,  expected  time  in  queue 

0.00001 

W,  expected  total  time  in  system 

0.00028 

Probability  that  data  waits  to  be  processed 

0.05% 

0.15  -| 

-  0/1  Jli 
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Figure  H-2.  Mathematical  model  results  for  802.16  Wireless-Laptop  and  802.16  Wireless  -SBC  systems. 

This  figure  captures  the  results  from  the  mathematical  model  results  for  Wireless-Laptop  and  Wireless-SBC  systems. 
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Table  H-l.  Throughput  Simulation  for  xCMA  System  Alternatives  1  and  2:  SATCOM-Laptop  and  SATCOM-SBC 


Single  Server  Queue 

Calculations  set  to  Manual.  Press  F9  to  recalculate. 


Packet 

# 

Time  between 
arrivals 

Arrival  time 

Queue 

length 

Start  service 

Service  time 

End  service 

Wait  time 

Idle 

Time 

Average  % 
Idle  Time 

Utilization 

Rate 

0 

0.00000 

0.00000 

0 

0.00000 

0.00000 

0.00000 

0.00000 

0.0000 

0% 

0.00% 

1 

0.01034 

0.01034 

0 

0.01034 

0.00186 

0.01219 

0.00000 

0.0103 

85% 

15.24% 

2 

0.00305 

0.01338 

0 

0.01338 

0.00005 

0.01343 

0.00000 

0.0012 

86% 

14.20% 

3 

0.01102 

0.02440 

0 

0.02440 

0.00022 

0.02463 

0.00000 

0.0110 

91% 

8.65% 

4 

0.00485 

0.02925 

0 

0.02925 

0.0031 1 

0.03237 

0.00000 

0.0046 

84% 

16.20% 

5 

0.00097 

0.03022 

1 

0.03237 

0.00602 

0.03839 

0.00215 

0.0000 

71% 

29.35% 

6 

0.00589 

0.03612 

1 

0.03839 

0.00325 

0.04164 

0.00227 

0.0000 

65% 

34.86% 

7 

0.00138 

0.03749 

2 

0.04164 

0.00393 

0.04556 

0.00414 

0.0000 

60% 

40.47% 

8 

0.02365 

0.06115 

0 

0.06115 

0.00250 

0.06365 

0.00000 

0.0156 

67% 

32.90% 

9 

0.01237 

0.07352 

0 

0.07352 

0.00196 

0.07547 

0.00000 

0.0099 

70% 

30.34% 

10 

0.00676 

0.08028 

0 

0.08028 

0.00378 

0.08406 

0.00000 

0.0048 

68% 

31.74% 

11 

0.00372 

0.08400 

1 

0.08406 

0.00264 

0.08670 

0.00006 

0.0000 

66% 

33.82% 

12 

0.00364 

0.08764 

0 

0.08764 

0.00096 

0.08860 

0.00000 

0.0009 

66% 

34.18% 

13 

0.01119 

0.09883 

0 

0.09883 

0.00101 

0.09984 

0.00000 

0.0102 

69% 

31.34% 

14 

0.00847 

0.10730 

0 

0.10730 

0.00528 

0.11258 

0.00000 

0.0075 

68% 

32.48% 

15 

0.00070 

0.10801 

1 

0.11258 

0.00271 

0.11528 

0.00457 

0.0000 

66% 

34.07% 

16 

0.00982 

0.11782 

0 

0.11782 

0.00303 

0.12086 

0.00000 

0.0025 

65% 

35.00% 

17 

0.00158 

0.11940 

1 

0.12086 

0.00273 

0.12359 

0.00146 

0.0000 

64% 

36.44% 

18 

0.00813 

0.12753 

0 

0.12753 

0.00100 

0.12852 

0.00000 

0.0039 

64% 

35.82% 

19 

0.00086 

0.12839 

1 

0.12852 

0.00764 

0.13616 

0.00014 

0.0000 

61% 

39.42% 

20 

0.00027 

0.12866 

1 

0.13616 

0.00221 

0.13837 

0.00751 

0.0000 

60% 

40.39% 

21 

0.00092 

0.12958 

2 

0.13837 

0.00064 

0.13902 

0.00880 

0.0000 

59% 

40.66% 

22 

0.00380 

0.13337 

3 

0.13902 

0.00118 

0.14020 

0.00565 

0.0000 

59% 

41.16% 

23 

0.00118 

0.13455 

4 

0.14020 

0.00175 

0.14195 

0.00564 

0.0000 

58% 

41.89% 

24 

0.00147 

0.13602 

5 

0.14195 

0.01095 

0.15289 

0.00592 

0.0000 

54% 

46.05% 

25 

0.00115 

0.13717 

5 

0.15289 

0.00640 

0.15930 

0.01572 

0.0000 

52% 

48.22% 

26 

0.02826 

0.16543 

0 

0.16543 

0.00391 

0.16935 

0.00000 

0.0061 

52% 

47.67% 

27 

0.01119 

0.17662 

0 

0.17662 

0.00191 

0.17854 

0.00000 

0.0073 

54% 

46.28% 

28 

0.00425 

0.18087 

0 

0.18087 

0.01503 

0.19591 

0.00000 

0.0023 

50% 

49.86% 

29 

0.00983 

0.19070 

1 

0.19591 

0.00477 

0.20067 

0.00521 

0.0000 

49% 

51.05% 

30 

0.00665 

0.19735 

1 

0.20067 

0.00344 

0.2041 1 

0.00332 

0.0000 

48% 

51.87% 

31 

0.00156 

0.19891 

2 

0.2041 1 

0.00083 

0.20494 

0.00521 

0.0000 

48% 

52.07% 

32 

0.00493 

0.20383 

2 

0.20494 

0.00908 

0.21402 

0.00111 

0.0000 

46% 

54.10% 

33 

0.00797 

0.21180 

1 

0.21402 

0.00084 

0.21486 

0.00222 

0.0000 

46% 

54.28% 

34 

0.00206 

0.21386 

2 

0.21486 

0.00017 

0.21503 

0.00101 

0.0000 

46% 

54.31% 

35 

0.01642 

0.23027 

0 

0.23027 

0.00251 

0.23278 

0.00000 

0.0152 

49% 

51.25% 

36 

0.00828 

0.23855 

0 

0.23855 

0.00069 

0.23925 

0.00000 

0.0058 

50% 

50.16% 

37 

0.00930 

0.24786 

0 

0.24786 

0.00046 

0.24832 

0.00000 

0.0086 

51% 

48.51% 

38 

0.00586 

0.25371 

0 

0.25371 

0.00236 

0.25607 

0.00000 

0.0054 

52% 

47.96% 

39 

0.00205 

0.25576 

1 

0.25607 

0.00505 

0.26112 

0.00031 

0.0000 

51% 

48.97% 

40 

0.00364 

0.25940 

1 

0.26112 

0.01224 

0.27336 

0.00173 

0.0000 

49% 

51.25% 

41 

0.01180 

0.27119 

1 

0.27336 

0.00291 

0.27627 

0.00216 

0.0000 

48% 

51.77% 

42 

0.00371 

0.27491 

1 

0.27627 

0.00169 

0.27796 

0.00137 

0.0000 

48% 

52.06% 

43 

0.00882 

0.28373 

0 

0.28373 

0.01405 

0.29779 

0.00000 

0.0058 

47% 

53.31% 

44 

0.00169 

0.28543 

1 

0.29779 

0.00392 

0.30170 

0.01236 

0.0000 

46% 

53.92% 

45 

0.00967 

0.29509 

2 

0.30170 

0.00016 

0.30186 

0.00661 

0.0000 

46% 

53.94% 

46 

0.00848 

0.30357 

0 

0.30357 

0.00071 

0.30428 

0.00000 

0.0017 

46% 

53.75% 

Based  on  1  replication: 

Num  of  Packets 

500 

Average  wait  time  (sec) 

0.00276305 

SD  of  Average  wait  time 

0.00482715 

Conf  Level 

95% 

Alpha 

5% 

Conf  Width  of  Average  wait  time  (sec) 

0.0004231 

Cl  Low  of  Average  wait  time  (sec) 

0.0023399 

Cl  High  of  Average  wait  time  (sec) 

0.0031862 

Num  of  PDs 

500 

Average  Utilization  Rate 

48.55% 

SD  of  Average  Utilization  Rate 

4.38% 

Conf  Level 

95% 

Alpha 

5% 

Conf  Width  of  Average  Utilization  Rate 

0.38% 

Cl  Low  of  Average  Utilization  Rate 

48.17% 

Cl  High  of  Average  Utilization  Rate 

48.93% 

Probability  that  data  waits  to  be  processed 

0.43% 

Based  on  30  replications: 

Num  of  Replications 

30 

Average  wait  time  (sec) 

0.0048588 

SD  of  Average  wait  time 

0.0011322 

Conf  Level 

95% 

Alpha 

5% 

Conf  Width  of  Average  wait  time  (sec) 

0.0004051 

Cl  Low  of  Average  wait  time  (sec) 

0.0044537 

Cl  High  of  Average  wait  time  (sec) 

0.0052640 

Num  of  Replications 

30 

Average  Utilization  Rate 

55.01% 

SD  of  Average  Utilization  Rate 

3.77% 

Conf  Level 

95% 

Alpha 

5% 

Conf  Width  of  Average  Utilization  Rate 

1.35% 

Cl  Low  of  Average  Utilization  Rate 

53.66% 

Cl  High  of  Average  Utilization  Rate 

56.35% 

Probability  that  data  waits  to  be  processed 

0.43% 

| Probability  that  the  system  throughput  >128  Kbps  99.57% 


Data  Table 


Avg  wait  time 

Utilization 

Run 

(sec) 

Rate 

1 

0.0027630 

48.55% 

2 

0.0062309 

59.90% 

3 

0.0046781 

59.65% 

4 

0.0054543 

49.89% 

5 

0.0048863 

56.17% 

6 

0.0080646 

59.74% 

7 

0.0044976 

57.27% 

8 

0.0061575 

53.88% 

9 

0.0035393 

50.23% 

10 

0.0039510 

54.38% 

11 

0.0038888 

52.21% 

12 

0.0040340 

57.59% 

13 

0.0041 

52.03% 

14 

0.0057 

52.47% 

15 

0.0050 

58.46% 

16 

0.0040 

58.61% 

17 

0.0048 

59.33% 

18 

0.0073 

55.47% 

19 

0.0046 

56.96% 

20 

0.0062 

63.70% 

21 

0.0052 

56.98% 

22 

0.0040 

52.41% 

23 

0.0047 

52.30% 

24 

0.0052 

49.96% 

25 

0.0052 

50.24% 

26 

0.0044 

54.40% 

27 

0.0052 

54.47% 

28 

0.0032 

56.82% 

29 

0.0045 

50.45% 

30 

0.0045 

55.71% 

Table  H-l  summarizes  the  xCMA  throughput  simulation  results  using  the  single  server  queue  excel  spreadsheet  model  for  the  SATCOM- 
Laptop  and  SATCOM-SBC  alternatives. 
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Table  H-2.  Throughput  Simulation  for  xCMA  System  Alternatives  3  and  4:  Wireless-Laptop  and  Wireless-SBC 


Single  Server  Queue 

Calculations  set  to  Manual.  Press  F9  to  recalculate. 


Packet 

# 

Time  between 
arrivals 

Arrival  time 

Queue 

length 

Start  service 

Service  time 

End  service 

Wait  time 

Average  % 
Idle  Time 

Utilization 

Rate 

0 

0.00000 

0.00000 

0 

0.00000 

0.00000 

0.00000 

0.00000 

0% 

0.00% 

1 

0.00897 

0.00897 

0 

0.00897 

0.00026 

0.00923 

0.00000 

97% 

2.82% 

2 

0.01098 

0.01995 

0 

0.01995 

0.00147 

0.02142 

0.00000 

92% 

8.09% 

3 

0.02646 

0.04640 

0 

0.04640 

0.00079 

0.04720 

0.00000 

95% 

5.35% 

4 

0.00345 

0.04985 

0 

0.04985 

0.00008 

0.04993 

0.00000 

95% 

5.22% 

5 

0.00140 

0.05125 

0 

0.05125 

0.00138 

0.05263 

0.00000 

92% 

7.57% 

6 

0.00223 

0.05348 

0 

0.05348 

0.00026 

0.05374 

0.00000 

92% 

7.90% 

7 

0.00508 

0.05855 

0 

0.05855 

0.00031 

0.05887 

0.00000 

92% 

7.74% 

8 

0.00096 

0.05951 

0 

0.05951 

0.00021 

0.05973 

0.00000 

92% 

7.99% 

9 

0.01878 

0.07829 

0 

0.07829 

0.00006 

0.07836 

0.00000 

94% 

6.17% 

10 

0.00327 

0.08156 

0 

0.08156 

0.00039 

0.08196 

0.00000 

94% 

6.38% 

11 

0.00707 

0.08864 

0 

0.08864 

0.00015 

0.08879 

0.00000 

94% 

6.06% 

12 

0.00757 

0.09620 

0 

0.09620 

0.00029 

0.09649 

0.00000 

94% 

5.87% 

13 

0.01365 

0.10985 

0 

0.10985 

0.00075 

0.11061 

0.00000 

94% 

5.81% 

14 

0.00278 

0.11263 

0 

0.11263 

0.00085 

0.11348 

0.00000 

94% 

6.41% 

15 

0.01091 

0.12354 

0 

0.12354 

0.00006 

0.12360 

0.00000 

94% 

5.93% 

16 

0.00067 

0.12421 

0 

0.12421 

0.00027 

0.12448 

0.00000 

94% 

6.10% 

17 

0.00746 

0.13167 

0 

0.13167 

0.00003 

0.13170 

0.00000 

94% 

5.79% 

18 

0.00312 

0.13480 

0 

0.13480 

0.00001 

0.13481 

0.00000 

94% 

5.67% 

19 

0.00164 

0.13643 

0 

0.13643 

0.00003 

0.13646 

0.00000 

94% 

5.62% 

20 

0.01074 

0.14717 

0 

0.14717 

0.00022 

0.14739 

0.00000 

95% 

5.35% 

21 

0.00671 

0.15388 

0 

0.15388 

0.00013 

0.15401 

0.00000 

95% 

5.21% 

22 

0.00336 

0.15724 

0 

0.15724 

0.00018 

0.15742 

0.00000 

95% 

5.21% 

23 

0.00489 

0.16213 

0 

0.16213 

0.00013 

0.16226 

0.00000 

95% 

5.13% 

24 

0.00136 

0.16349 

0 

0.16349 

0.00054 

0.16403 

0.00000 

95% 

5.41% 

25 

0.01270 

0.17620 

0 

0.17620 

0.00004 

0.17624 

0.00000 

95% 

5.05% 

26 

0.02594 

0.20214 

0 

0.20214 

0.00029 

0.20243 

0.00000 

95% 

4.54% 

27 

0.00606 

0.20820 

0 

0.20820 

0.00113 

0.20933 

0.00000 

95% 

4.93% 

28 

0.00094 

0.20914 

1 

0.20933 

0.00048 

0.20981 

0.00019 

95% 

5.15% 

29 

0.00209 

0.21123 

0 

0.21123 

0.00022 

0.21144 

0.00000 

95% 

5.22% 

30 

0.01765 

0.22887 

0 

0.22887 

0.00064 

0.22951 

0.00000 

95% 

5.08% 

31 

0.00885 

0.23772 

0 

0.23772 

0.00014 

0.23786 

0.00000 

95% 

4.97% 

32 

0.00229 

0.24001 

0 

0.24001 

0.00025 

0.24025 

0.00000 

95% 

5.02% 

33 

0.00525 

0.24526 

0 

0.24526 

0.00002 

0.24528 

0.00000 

95% 

4.92% 

34 

0.00270 

0.24795 

0 

0.24795 

0.00024 

0.24819 

0.00000 

95% 

4.96% 

35 

0.01316 

0.26111 

0 

0.26111 

0.00103 

0.26214 

0.00000 

95% 

5.09% 

36 

0.00485 

0.26596 

0 

0.26596 

0.00006 

0.26602 

0.00000 

95% 

5.04% 

37 

0.00384 

0.26979 

0 

0.26979 

0.00003 

0.26982 

0.00000 

95% 

4.98% 

38 

0.00077 

0.27056 

0 

0.27056 

0.00037 

0.27093 

0.00000 

95% 

5.10% 

39 

0.02161 

0.29218 

0 

0.29218 

0.00060 

0.29277 

0.00000 

95% 

4.92% 

40 

0.00832 

0.30050 

0 

0.30050 

0.00018 

0.30068 

0.00000 

95% 

4.85% 

41 

0.02616 

0.32665 

0 

0.32665 

0.00004 

0.32669 

0.00000 

96% 

4.48% 

42 

0.01502 

0.34168 

0 

0.34168 

0.00004 

0.34172 

0.00000 

96% 

4.29% 

43 

0.00733 

0.34901 

0 

0.34901 

0.00007 

0.34908 

0.00000 

96% 

4.22% 

44 

0.01018 

0.35918 

0 

0.35918 

0.00004 

0.35923 

0.00000 

96% 

4.11% 

45 

0.00915 

0.36833 

0 

0.36833 

0.00019 

0.36852 

0.00000 

96% 

4.06% 

46 

0.01537 

0.38370 

0 

0.38370 

0.00015 

0.38385 

0.00000 

96% 

3.94% 

Arrival  Distribution:  Exponential 
=-  (1/ p  )*LN(rand()) 
p  =  |  128  |  Kbps 


Service  Distribution:  Exponential 
=-  (1/  p)*LN(rand()) 

M  =  |  3,729  Kbps 


Based  on  1  replication: 

Num  of  Packets 

500 

Average  wait  time  (sec) 

0.00000879 

SD  of  Average  wait  time 

0.00005519 

Conf  Level 

95% 

Alpha 

5% 

Conf  Width  of  Average  wait  time  (sec) 

0.0000048 

Cl  Low  of  Average  wait  time  (sec) 

0.0000040 

Cl  High  of  Average  wait  time  (sec) 

0.0000136 

Num  of  PDs 

500 

Average  Utilization  Rate 

3.73% 

SD  of  Average  Utilization  Rate 

0.68% 

Conf  Level 

95% 

Alpha 

5% 

Conf  Width  of  Average  Utilization  Rate 

0.06% 

Cl  Low  of  Average  Utilization  Rate 

3.67% 

Cl  High  of  Average  Utilization  Rate 

3.79% 

Probability  that  data  waits  to  be  processed 

0.03% 

Based  on  30  replications: 

Num  of  Replications 

30 

Average  wait  time  (sec) 

0.0000081 

SD  of  Average  wait  time 

0.0000031 

Conf  Level 

95% 

Alpha 

5% 

Conf  Width  of  Average  wait  time  (sec) 

0.0000011 

Cl  Low  of  Average  wait  time  (sec) 

0.0000070 

Cl  High  of  Average  wait  time  (sec) 

0.0000093 

Num  of  Replications 

30 

Average  Utilization  Rate 

3.50% 

SD  of  Average  Utilization  Rate 

0.37% 

Conf  Level 

95% 

Alpha 

5% 

Conf  Width  of  Average  Utilization  Rate 

0.13% 

Cl  Low  of  Average  Utilization  Rate 

3.37% 

Cl  High  of  Average  Utilization  Rate 

3.63% 

Probability  that  data  waits  to  be  processed 

0.03% 

[Probability  that  the  system  throughput  >128  Kbp  99,97% 


Data  Table 


Run 

Avg  wait  time 

Utilization 

Rate 

1 

0.00000879 

3.73% 

2 

0.00001142 

3.23% 

3 

0.00000866 

4.11% 

4 

0.00000446 

3.25% 

5 

0.00000794 

3.07% 

6 

0.00000748 

3.56% 

7 

0.00000733 

3.83% 

8 

0.00000336 

3.58% 

9 

0.00000710 

3.72% 

10 

0.00000472 

3.01% 

11 

0.00001090 

3.41% 

12 

0.00000830 

3.06% 

13 

0.00000696 

3.46% 

14 

0.00001302 

3.85% 

15 

0.00001268 

3.75% 

16 

0.00000753 

3.37% 

17 

0.00000736 

4.15% 

18 

0.00000498 

3.04% 

19 

0.00000849 

2.97% 

20 

0.00001202 

4.06% 

21 

0.00000219 

3.68% 

22 

0.00000913 

3.42% 

23 

0.00000552 

3.51% 

24 

0.00000661 

3.36% 

25 

0.00000690 

3.24% 

26 

0.00001028 

3.82% 

27 

0.00000765 

3.07% 

28 

0.00000702 

3.37% 

29 

0.00001740 

4.20% 

30 

0.00000832 

3.11% 

Table  H-2  summarizes  the  xCMA  throughput  simulation  results  using  the  single  server  queue  excel  spreadsheet  model  for  the  Wireless- 
Laptop  and  Wireless-SBC  alternatives. 
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APPENDIX  I.  LIST  OF  ACRONYMS 


AIS 

AOI 


C2 

C4ISR 

CBA 

CBT 

CENTRIXS 

CMA 

CNO 

COE 

COI 

COMMS 

COMPACFLT 

CONOPS 

CONUS 

COTS 

CPU 

CRT 


D-GPS 

DAPM 

DEIP 

D-GPS 

DOD 

DoDAF 

DoS 

DOTMLPF 


ECP 


FAA 

FFBD 

FYDP 


-  A- 

Automatic  Identification  System 
Area  of  Interest 


-B- 

-C- 

Command  and  Control 

Command,  Control,  Communications,  Computers,  Intelligence 
Surveillance  Reconnaissance 
Capabilities  Based  Assessment 
Computer  Based  Training 

Combined  Enterprise  Regional  Information  Exchange  System 

Comprehensive  Maritime  Awareness 

Chief  of  Naval  Operations 

Center  of  Excellence 

Community  of  Interest 

Communications 

Command  Pacific  Fleet 

Concept  of  Operations 

Continental  United  States 

Commercial-Off-The-Shelf 

Central  Processing  Unit 

Cathode  Ray  Tubes 


-D- 

Differential  Global  Positioning  System 
Deputy  Assistant  Program  Manager 
Dynamic  Enterprise  Integration  Platfonn 
Differential  GPS 
Department  of  Defense 

Department  of  Defense  Architecture  Framework 
Department  of  State 

Doctrine,  Organization,  Training,  Materiel,  Leadership  and 
Education,  Personnel,  and  Facilities 

-E- 

Experimental  Campaign  Plan 

-F- 

Federal  Aviation  Administration 
Functional  Flow  Block  Diagram 
Future  Years  Defense  Plan 
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-G- 

GMCOI 

Global  Maritime  Community  of  Interest 

GMI 

Global  Maritime  Intelligence 

GMII 

Global  Maritime  Intelligence  Integration 

GMSA 

Global  Maritime  Situational  Awareness 

GPS 

Global  Positioning  System 

GUI 

Graphical  User  Interface 

-H- 

Hrs 

Hours 

HSPD 

Homeland  Security  Presidential  Directive 

HSI 

Human  System  Interface 

IDEFO 

-I- 

Integration  Definition  for  Function  Modeling 

IEEE 

Institute  of  Electrical  &  Electronics  Engineers 

IP 

Internet  Protocol 

IPR 

In-Progress  Review 

JCTD 

-  J- 

Joint  Capabilities  Technology  Demonstration 

JFC 

Joint  Forces  Command 

JOA 

Joint  Operations  Area 

JOG 

Joint  Operations  Center 

LCD 

-L- 

Liquid  Crystal  Display 

LOS 

Line  of  Sight 

LRIT 

Long  Range  Identification  and  Tracking 

-  M  - 

M&S 

Modeling  and  Simulation 

MAC 

Media  Access  Control 

MAUT 

Multi- Attribute  Utility  Theory 

Mbps 

Megabytes  per  second 

MDA 

Maritime  Domain  Awareness 

MHQ 

Maritime  Headquarters 

MIEM 

Maritime  Information  Exchange  Model 

MIFCLANT 

Maritime  Intelligence  Fusion  Center  Atlantic 

MIFCPAC 

Maritime  Intelligence  Fusion  Center  Pacific 

MLS 

Multi-Level  Security 

MOC 

Maritime  Operations  Center 

MODEM 

Modulator  Demodulator 
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MOE 

MOP 

MOTR 

MSPCC 

MTBF 

MTE 


NAVEUR 

NIC 

NMIC 

NORAD 

NPS 

NSMS 

NSPD 


ov 


PDA 
PEO  C4I 

PLI 

PMW 


QFD 


RF 


SATCOM 

SBC 

SDR 

SOA 

SOW 

SPAWAR 

SV 


TRL 

TSAT 


Measures  of  Effectiveness 

Measures  of  Performance 

Maritime  Operational  Threat  Response 

Maritime  Security  Policy  Coordinating  Committee 

Mean  Time  Between  Failure 

Mobile  Terminal  Equipment 

-N- 

Naval  Command  Europe 

Network  Interface  Card 

National  Maritime  Intelligence  Center 

North  American  Aerospace  Defense  Command 

Naval  Postgraduate  School 

National  Strategy  for  Maritime  Security 

National  Security  Presidential  Directive 

-O- 

Operational  View 

-P- 

Personal  Digital  Assistant 

Program  Executive  Office,  Command,  Control,  Communications, 
Computers,  Intelligence 
Position  Location  Infonnation 
Program  Manager,  Warfare 


-Q- 

Quality  Functional  Deployment 

-R- 

Radio  Frequency 

-S- 

Satellite  Communications 
Single  Board  Computer 
Software  Definable  Radios 
Services-Oriented  Architecture 
Statement  of  Work 

Space  and  Naval  Warfare  Systems  Command 
Systems  View 


-T- 

Technology  Readiness  Level 
Transformational  Communications  Satellite 
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UDAP 

UDOP 

UHF 

UML 

US 

USEUCOM 

USNORTHCOM 

USPACOM 


VHF 


xCMA 


-U- 

User  Defined  Awareness  Picture 
User  Defined  Operational  Picture 
Ultra  High  Frequency 
Universal  Modeling  Language 
United  States 

United  States  European  Command 
United  States  Northern  Command 
United  States  Pacific  Command 

-  V- 

Very  High  Frequency 

-X- 

Extending  Comprehensive  Maritime  Awareness 
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